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KÖSZÖNTŐ 


2000. október 12-én jelentette be San Francis- 
co-ban, az Intel Exchange konferencián Bill 
Gates a .NET rendszerfelügyeleti stratégiát, 
melyről a .NET kiszolgálók körüli sürgés-forgás 
közepette hazánkban eddig kevesebb szó 
esett. Pedig nagy változások történtek ezen a 
téren, illetve vannak még készülőfélben. 
Rögtön először itt van maga a tény, hogy egy- 
séges rendszerfelügyeleti stratégiát hirdetett 
meg a Microsoft. A cégen belül egy több mint 
500 főt számláló fejlesztőrészleg jött létre, amely kizárólag 
menedzsment technológiákkal foglalkozik. A részleg a Win- 
dows 2000 fejlesztőcsapat alá került, így közvetlenül Brian 
Valentine a vezetője (ő korábban az Exchange fejlesztését ve- 
Zette, egészen az 5.5-ös verzióig). 

Most tehát Brian Valentine alá tartozik a Systems Manage- 
ment Server fejlesztése is, ő pedig (a korábbi termékein is 
megfigyelhetjük) igazán ad a kód minőségére. Az SMS tovább- 
ra is stratégiai fontosságú menedzsment terméke a Microsoft- 
nak - már megjelent az SMS 2.0 SP3, a következő mérföldkő 
pedig az SMS , Topaz" kódnevű változata lesz, mely valamikor 
idén télre várható. A , Topaz" nem lesz ,SMS2000" csak ,2.x", 
tehát csak egy kisebb verzióváltás. Főleg a minőségre össz- 
pontosít, az új funkciók az Active Directory integráció és a 
mobil ügyfelek jobb támogatása lesznek. 

Fontos látnunk az SMS szerepét a termékstratégiában, hiszen 
sajnos sok helyen már az új, Microsoft Operations Manager ter- 
méket emlegetik az SMS utódjaként. Erről szó sincs! (Sajnos a 
Tech.net magazin egyik korábbi számában is hibásan jelent ez 
meg). A Microsoft Operations Manager (már beceneve is van: 
MOM) egy teljesen más területre ad megoldást: míg az SMS az 
új hardverelemek, operációs rendszerek és alkalmazások beve- 
zetését, tehát a környezet megváltozását kezeli a leltározási és 
szoftverdisztribúciós funkciókkal, addig a MOM már ennek a 
megváltozott környezetnek az üzemeltetésére szolgál. (Mert 
amit bevezettünk, azt ugye még folyamatosan figyelni is kell, 
hogy jól működik-e...) A MOM az SMS-beli Health Monitor 
feladatát valósítja meg nagyságrendekkel magasabb szinten: 
esemény-, és teljesítményadatok gyűjtését és konszolidálását 
több forrásból, SOL Server adatbázisba (WMI, SNMP csapdák, 
Windows NT/2000 rendszernapló, alkalmazásnaplók, stb.), au- 
tomatikus válaszlépések és riasztások megtételét bizonyos 
események bekövetkeztekor illetve teljesítményküszöbök át- 
lépésekor, és jelentések készítését az összegyűjtött adatokból 
hibakeresés és kapacitástervezés céljából. 

A MOM egyelőre csak a Microsoft alkalmazáskiszolgálóinak 
üzemeltetését fogja támogatni, azonban a lényege éppen a 
fejleszthetőségen van: a MOM egy üzemeltetési platform, 
melynek nyílt az SDK-ja, bárki fejleszthet hozzá modulokat, 
ún. , Management Pack"-eket. Az első ilyen cég a NetIO lesz, 
nem véletlenül: a MOM eredeti kódját ugyanis tőlük licencel- 
te a Microsoft. A NetI0 a MOM megjelenése után nem folytat- 
ja saját Operations Manager termékének gyártását, helyette a 
MOM-hoz illeszkedő, harmadik gyártók termékeinek üzemelte- 
tésére szolgáló csomagokat készít majd. (SAP, Notes, Oracle, 
ArcServer, Compag, HP, Dell, IBM hardverek moduljai, stb.) 

A .NET rendszerfelügyeleti stratégiának éppen ez a központi 
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eleme: az első célkitűzés, hogy a Windows környezet jól ke- 
zelhető platform legyen, a második az, hogy maguk a me- 
nedzsmenteszközök fussanak Windowson, és akár innen 
felügyeljenek más platformot is. Ennek titka természetesen az 
operációs rendszerbe épített gazdag felügyeleti technológiák- 
ban és szolgáltatásokban rejlik, melyek megkönnyítik a fejlesz- 
tők dolgát. Nincs messze az idő, amikor a NetWare, Linux, Sola- 
ris kiszolgálóinkat is Windows platformról menedzseljük (MOM 
menedzsment csomag legalábbis lesz ezekhez a platformokhoz). 
Idővel tehát a legtöbb rendszerfelügyeleti funkció beleolvad 
majd az operációs rendszerbe. Erre jó példa a még csak Béta 
2 állapotban lévő Windows XP Professional: itt az asztali op- 
rendszernek is része a terminálszolgáltatás, így a távirányí- 
tási feladatok beépítetten, minden további eszköz telepítése 
nélkül oldhatók meg. 

Persze azt elfelejtettem említeni, hogy minden XML alapú 
lesz. Az üzleti folyamatokat majd a BizTalk képzi le üzemelte- 
tési és rendszerfelügyeleti lépésekre, és vezényli XML alapon 
az egyes eszközök működését. Az Interneten át könnyedén 
kommunikálhatnak a menedzsmenteszközök HTTP alapon, 
XML-be ágyazott SOAP üzenetekkel. Mivel bárhol, bármikor, 
tetszőleges eszközről tudnunk kell menedzselni a rendszerün- 
ket, az MMC alapú konzolok szerepét a webes konzol, az MMC 
Portál váltja fel. Ez a felszínen ugyan csak egy HTML megje- 
lenítő réteg, de a mélyén XML-en alapuló, minden egyes mű- 
velet szkriptelését megengedő keretrendszer lapul. 

Az ilyen környezetek felügyeletéhez és üzemeltetéséhez per- 
sze sokéves szakmai tapasztalat szükséges. Ezt a gyakorlati 
tudást és tapasztalatot próbálja meg rendszerezetten átadni 
a Microsoft az Operations Framework üzemeltetési keretrend- 
szerben. A MOF nem egy termék, hanem egy módszertan: fi- 
zikailag az üzemeltetés egyes területein bevált fogások, 
megoldások, szabályok és ajánlások dokumentációinak gyűj- 
teménye. Az üzemeltetésnek egyébként része a terméktámo- 
gatás (Help Desk) is, ahol a Microsoft-nak egyelőre nincs tel- 
jes terméke, ám a Windows XP Professional-ban már megjele- 
nik a Support Automation Framework (SAF), mely egy fejlesz- 
tési keretrendszer - eszközkészletet, eljáráskönyvtárt ad a tá- 
mogatási rendszerek fejlesztőinek az alkalmazások készítésé- 
hez. Talán mondani sem kell, hogy a SAF is XML alapú, így 
harmadik gyártók Help Desk eszközei könnyen integrálhatók 
vele. A Windows XP így valóban jól felügyelhető, üzemeltet- 
hető és támogatható vállalati asztali ügyfél lesz. 

Úgy tűnik tehát, hogy a 2001-es év a rendszerfelügyelet és az 
üzemeltetés jegyében (is) telik a Microsoft-nál. Május 2-án a 
Lurdy házban azonban mindenképp. A TechNet szeminárium- 
sorozat keretében Tarsoly Balázs kollégámmal ekkor a fenti 
technológiákról egy kicsit bővebben is beszélünk. Mindenkit 
szeretettel várunk. 


Horváth Tamás 
Rendszermérnök 
Microsoft Magyarország 
tamash emicrosoft.com 
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ae. Nyilvános és letölthető az Inter- 
Internet ő 

é Explorer net Explorer 6 béta . 

Az Internet Explorer 6 preview web- 
helyéről [1] letölthető az Internet Explorer 6 béta változa- 
ta. Akik már látták, azt mondják, hogy az IE6 nem jelent 
majd óriási lépést a jelenlegi verziókhoz képest. Bár levele- 
zésért és a hírolvasásért felelős komponens, az Outlook 
Express egyáltalán nem változott lényegesen, a böngésző- 
ben azért lesz néhány érdekes újdonság: 

"0 Kép-eszköztár (Image Toolbar): néhány új funkció a ké- 
pek kezeléséhez, kép mentése, küldése, nyomtatása 
közvetlenül az oldalból 

"0 Automatikus képátméretezés: ha egy kép kilógna a bön- 

gésző felületéről, az IE6 automatikusan átméretezi azt (a 

méretezés követi a böngésző ablakának méretváltozásait is) 

Beépített üzenetkezelés: az MSN Messenger azonnali 

üzenetkezelő program beépült a böngészőbe, ezentúl 

könnyen elérjük a címlistánkban található felhasználó- 
kat és az instant messaging szolgáltatásokat 

"b P3P és egyéb biztonsági szolgáltatások: a P3P a World 
Wide Web Consortium (W3C) által fejlesztett szabvány 
[2]. A P3P-nek köszönhetően a felhasználók közvetlenül 
meghatározhatják, hogy egy adott webhely milyen infor- 
mációkhoz fér hozzá. Az IE6 képes a cookie-k szűrésére is 

0 Hibajelentés: valószínűleg mindannyiunkkal megtörtént 
már, hogy böngészés kellős közepén az IE beadta a kul- 
csot. Az IE6-ban lehetőségünk van a hibát a Microsoft 
felé jelenteni. Ha a hiba ismert, a válasz akár egy javí- 
tócsomag vagy hotfix címe is lehet 
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Baklövés a VeriSign-nál 

A VeriSign Inc., a világ egyik legnagyobb digitális tanúsítvá- 
nyokat kiadó szervezete értesítette a Microsoftot, hogy 2001. 
január 30-án és 31-én két VeriSign Class 3 tanúsítványt adott 
ki egy magát Microsoft alkalmazottnak valló egyénnek. A 
kiadott tanúsítványok szoftverkomponensek és scriptek digi- 
tális aláírására használhatók, és úgy tűnik, mintha azokat a 
Microsoft Corporation" adta volna ki. A hamis tanúsítványok 
segítségével aláírt rendszerkomponensek például egy-egy do- 
kumentum megnyitásakor a bennük található scriptek segít- 
ségével lefuthatnak, miközben a gyanútlan felhasználó azt hi- 
szi, a Microsoft-tól származó programot futtat. 
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Internet 
Explorer 6 


A VeriSign természetesen visszavonta a tanúsítványokat (a 
visszavont tanúsítványok listája — Certificate Revocation List — 
már tartalmazza) , csakhogy a VeriSign által kiadott tanúsít- 
ványok nem tartalmazzák a visszavont tanúsítványokat tar- 
talmazó lista letöltési helyét (CLR Distribution Point, CDP). 
A javítás a Windows 95 óta megjelent összes Windows ope- 
rációs rendszereken futó IE4.01 SP2, IE5.01 SP1, IE5.01 
SP2, IE5.5 SP1 böngészőkhöz készült, és a [3] címről tölt- 
hető le. A javítást a Windows 2000 Service Pack 2, az In- 
ternet Explorer 6 és a Windows XP Gold (gyártásra kész, vég- 
leges) verziója tartalmazza majd, ezek megjelenéséig az 
érintett böngészők újratelepítése vagy rendszerfrissítés 
(W2000-re, WXP-re) után a hotfixet újra kell telepíteni. 

Ha a javítást még nem telepítettük, az ellenőrzést kézzel is 
elvégezhetjük. A digitálisan aláírt programok futtatása 
előtt megjelenő figyelmeztető dialógusablakban ellenőriz- 
zük a tanúsítványokat. (Kattintsunk az aláíró nevére). Ha a 
tanúsítvány kiadási dátuma 1/29/2001 vagy 1/30/2001, a 
tanúsítványkiadó (Issued by:) ,VeriSign Commercial Soft- 
ware Publishers CA", a tulajdonos pedig (Issued To:) a 
"Microsoft Corporation", akkor a tanúsítvány hamis, ne fut- 
tassuk a programot, amihez , ragasztották". Ezeken a napo- 
kon a Microsoft részére nem készült valódi tanúsítvány. 
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Végül két megjegyzés: 

0 A Microsoft soha nem küld levélben programot (csak 
tiszta forrásból származó szoftvert futtassunk) 

0 A digitális tanúsítvány kiadása előtt a tanúsítványt 
kérő személy személyazonosságának ellenőrzése a ta- 
núsítványkiadó szervezet dolga. 

A témáról részletesen a [4] címen olvashatunk. 

XP-hírek A a 

Mindenekelőtt: itt a Windows (3) 

XP béta 2, amihez a hivatalos 

tesztelők, és a fejlesztők 


Ap) 
Microsoft" / e - 
máris hozzájuthatnak. Az Windows"P 
MSDN Professional és Univer- 


sal előfizetők letölthetik a webről, vagy várhatnak a követ- 
kező CD-szállítmányra. A Windows XP béta 2-t már aktiválni 
kell, az MSDN előfizetők ehhez egy 10 aktiválás erejéig érvényes 
kódot kapnak. 

A tesztelők inmár a Windows XP béta 2-höz készült hard- 
verkompatibilitási listát (HCL) is elérhetik [5]. Az érdeklő- 
dők látogassák meg a Windows XP hivatalos webhelyét a 
[6] címen, és ne hagyják ki a Windows SuperSite béta 2 
tesztjét se! [7]. 


A cikkben található URL-ek: 
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Jégeső! 

A Microsoft március 19-én bejelentette a .NET vízió-család 
legújabb elemét, az intelligens, XML alapú webes megoldá- 
sok fejlesztését támogató HailStorm (kb. jégeső) technoló- 
giát. A megoldás a már széleskörűen használt Microsoft 
Passport-ra alapul, és egyik fő célja az lenne, hogy egysé- 
gesítse a felhasználók különféle webhelyeken történő azo- 
nosítását úgy, hogy a felhasználó adatai mindvégig a fel- 
használó tulajdonában maradnak, és ő dönthet azok fel- 
használhatóságáról. [8] A témáról későbbi számainkban 
részletesebben is szólunk majd. 


Microsoft 





[1] http://www.microsoft.com/windows/ie/preview 
[2] http://www.w3.org/P3P/ 


[3] http://www.microsoft.com/downloads/release.asp?ReleaseID-28888 
[4] http://www.microsoft.com/technet/security/bulletin/MS01-017.asp 


[5] http://www.microsoft.com/hcl/default.asp 

[6] http://www.microsoft.com/windowsxp 

[7] http://www.winsupersite.com/reviews/windowsxp. beta2.asp 
[8] http://www.microsoft.com/net/hailstorm.asp 
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MAGDIKA, MIT HALLOTT ARRÓL, 
HOGY A KÖVETKEZŐ FOCIVÉ- 
BÉN MI FOGJUK KOMPOSZTÁL- 
NI AZ OBJEKTUMOKAT? 
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Sok érdekeset és jót hallottunk már a Windows XP, avagy a 
bennfentesebbek számára Whistler operációs rendszerről. Ké- 
pernyőképek jelentek meg a Weben, melyek igazolják, hogy a 
számunkra, informatikusok számára oly érdektelen felhaszná- 
lói felületen mi minden változott. Még szerencse, hogy a csi- 
csamicsa kikapcsolható lesz :) 

Én azonban azért ragadtam billentyűzetet, hogy egy kicsit a 
lényegi dolgokról is szó essék, s így jelen cikkben kizárólag 
díszítési elemként használom a felhasználói felületről készí- 
tett fotókat... Nem hiába telt el 1-2 év a Windows 2000 kód- 
jának lezárása óta, hisz megint olyan új felhasználói igények 
és ötletek merültek fel, melyeket egy új operációs rendszer- 
nek hoznia kell. 


Whistler 


pont CD-t nem tud írni kedvenc op-rendszerünk? 

"5 User switching. Különösen az otthoni felhasználók fogják 
szeretni ezt a szolgáltatást, ahol a kényszerű ki-be jelent- 
kezésnek biztonsági okai nincsenek, sokkal inkább arra 
használjuk a profilokat, hogy apu munkához használatos 
desktopját ne árasszák el a gyerek játékainak shortcutjai, 
környezetben a kijelentkezés felesleges nyűg, amely a 
munkakörnyezet elveszítésével jár, mikor a gyerek csak 
egy emailt akar írni. A User Switching lehetővé teszi, 
hogy (hasonlóan a Terminal Serviceshez, s az ötlet is on- 
nan jött) egynél több munkamenet álljon bejelentkezve 
készenlétben, amelyek között név-ijelszó megadással le- 
het majd váltogatni. Egyelőre kell hozzá helyes név és jel- 
szó, de Redmondban, a Microsoft Research-nél már túl- 
léptek ezen. Az Easy Living project keretében épült egy 
olyan ház, amelyik felismeri a lakóit, és tudja, hol vannak 


az épületben. Emiatt azt is tudja, hogy éppen ki, melyik 
családtag veszi éppen kezébe a háztartás egyetlen, drót- 
nélküli billentyűzetét - és már switcheli is a kívánt fel- 
használói felületet. Még pár év és ez is a mienk lesz :( 


Control Panel 


Pick a category 
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5 Így néz ki a Control Panel a Windows XP-ben 


Top-down 

Haladjunk a felszínes izéktől a tényleg fontos szolgáltatások 

felé, tehát még mielőtt végleg elmerülnénk a rendszer mély 

rejtelmeiben, vegyük sorra, mi mindennel próbálnak minket 
elcsábítani a marketingesek. 

"0 Itt van mindjárt a gyorsított rendszertöltés. Mivel Professi- 
onal-t nem is telepítettem, teljesen autentikus Advanced 
Server mérési eredményeim vannak a bootolás sebességé- 
ről: negyedannyi időbe telik, mint szegény , öreg" Win2K- 
nak. Ez már majdnem az OnNow sebessége, mely kezde- 
ményezés célkitűzése a bekapcsolás utáni azonnali hasz- 
nálatba vétel elérhetővé tétele - s nem ám hibernálással! 

0 Azután ki ne emlékezne borzongással a Windows 2000 
kezdeti néhány hónapjára, amikor semmilyen módon nem 
lehetett vele CD-t írni, mert ő ugye nem, de az Easy CD 
Creator sem, meg a Nero sem. Persze, most már könnyű! 
De ha megemlítem, hogy a Whistler magától tudni fogja 
a CD írást, azt hiszem érdekes részletet árulok el. S miért 
is ne írná? Gondolkodott már valaki azon, hogy miért 
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5 A Start menü is megváltozik 
És most következzen valami félkomoly... 


Active Directory 2.0 

Noha az Active Directory mára már fényesen bebizonyította 
stabilitását és méretezhetőségét, azért azt hozzá kell ten- 
nünk, hogy kényelmes használatához hiányzik még egy-két 
dolog. Például nem lehet az objektumokat drag-and-drop 
módszerrel áthelyezni máshova. Az még csak hagyján, hogy 
másik 0U-ba nem így kell, mert azt legalább lehet. De másik 
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tartományba, fába, erdőbe semmilyen egerészős módszerrel 
nem lehet! Hacsak az utólag telepíthető Active Directory Mi- 
gration Toolt nem tekintjük egerészős megoldásnak. De nem 
az. Szigorú tervezést igényel minden tett, amire ezzel az esz- 
közzel vetemedünk 

- A Whistler mindezt tudja. 

Azután ott van a rendszergazdák életének megszomorításá- 
ra az a fantasztikus lehetőség-hiány, hogy egyszerre egynél 
több user-en változtassak bármit. Nem megy! Amint egynél 
többet jelölünk ki, eltűnik a Properties menüpont! Sic! Jö- 
het a NetAcademia script tanfolyam, és máris ezresével ke- 
zelhetjük az objektumokat :) 

- A Whistler ezt is tudja. 

No meg a Global Catalog rémálom. Manapság ha nincs GC, 
nincs bejelentkezés. Még akkor is így van ez, ha a GC-nek 
nincs is értelme, mert egytartományos a környezet, ráadásul 
Universal csoportokat sem hoztunk létre. 

- A Whistler-ben ezt is megoldották. 

És ugye az ominózus csoportobjektum, melynek egyetlen, gi- 
gászivá dagadó attribútuma hordozza a csoport tagsági in- 
formációit. Ennek egyenes következménye, hogy egyidejű 
csoporttagság-módosításokkal könnyen adatvesztésre tud 
jutni két rendszergazda, hisz a replikáció nem tud finomabb 
egységet replikálni, mint egyetlen atribútumot. Nem mintha 
magyar ember valaha az életben találkozna ezzel az egyéb- 
ként könnyedén elkerülhető replikációs problémával, de 
azért ami csúnya, az csúnya. 

- Némi sémamódosítás árán ez a szerencsétlenség is begyó- 
gyul a Whistler-ben. 

Sok jelenlegi parancssori eszköz grafikus arcot kap, úgyhogy to- 
vább fog dagadni az Administrative Tools menüpont. Azt hallot- 
tam (de látni nem láttam), hogy az NTDSUTIL kap majd grafi- 
kus arcot, ami meg fogja könnyíteni az igazán advanced Acti- 
ve Directory feladatok végrehajtását. Egérrel lehet majd többek 
között offline töredezettségmentesítést végezni, a Configurati- 
on partícióból törölni, Authoritative Restore-t csinálni stb. 





(EBs57 (ez) (Eszi gl 
5 A Whistler kompatibilitás-varázslója 


Most pedig beszéljünk valami igazán komoly dologról... 


Komoly újdonságok az AD-ben 

A madarak csiripelése szerint az Active Directory-n nemcsak 

ráncfelvarrást hajtanak végre, hanem bele is nyúlnak jócskán. 

-5 Például lehetővé fog válni átmeneti, illékony objektu- 
mok és attribútumok létrehozása, melyeket eddig nem 
illett az AD-ben tárolni, hisz minden adat huss, kiment 
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WINDOws 2000 WHISTLER 
az NTDS.DIT fájlba, majd szétreplikálódott. Az átmeneti 
objektumok replikációja ki/be kapcsolható, és csak me- 
móriában vannak, azaz nem fogják össze-vissza tördelni 
az NTDS.DIT-et állandó létrejövésükkel és törlődésükkel. 
Ezzel megnyílik az út olyan adatok központi kezelésére, 
amelyekről eddig csak álmodtunk: 

8 Végre látszódhat az AD-ben, hogy egy felhasználó 

vagy gép be van-e jelentkezve, mert fel lehet végre 

venni az attribútumok közé, hogy a gépnek van-e 

Secure Channelje (azaz be van-e kapcsolva), a user- 

nek meg van-e Kerberos jegye 

Végre nem lesz fél-legális az Active Directory Integ- 

rated DNS zóna 
"9 Stb. 

-£ A meglévő három egész (plusz egy megtűrt) partíció 
(Schema, DC, Configuration, 4-1 GC) mellé az alkalmazás- 
fejlesztők maguk is készíthetek partíciókat, melyeknek 
replikációs viselkedését ők maguk írhatják majd le! 

-6 Virtual list view (VLV). Valami olyasmi, hogy az egy, 
megcsontosodott OU hierarchián kívül más nézőpont- 
ból is rácsodálkozhatunk majd az AD-re. Azaz nézetet 
válthatunk. Unom az OU hierarchiát, hadd lássam más 
szerint felfűzve! 


A fej nélküli lovas 

Érdekes megoldásnak tűnik számomra a headless operation, 
magyarul orcátlan futás. Ez azt jelenti, hogy az elindított 
Whistler-nek egyáltalán nincs képernyője, billentyűje, egere. 
Mi több, a headless futáshoz ki kell szedni a videokártyát a 
gépből, mert ha a rendszerindítás talál ilyet, használatba ve- 
szi. Azaz a headless működéshez megfelelő BIOS is kell, 
amely elviseli a videokártya hiányát. Mire jó mindez? Hogy 
a kiszolgálót betehessük az ellenség hűtőkamrájába, a 
Un"xok közé. Persze ehhez más is kell: teljes körű rendszer- 
felügyeleti lehetőség hálózaton keresztül. Nem, nem a Ter- 
minal Services, mert azzal egy-két dolgot nem lehet megcsi- 
nálni, s azért sem, mert ha a hálózatot konfiguráljuk halál- 
ba, akkor a Terminalozásnak lőttek. Nem úgy a telnetelés- 
nek, ami akár TCP/IP-n, akár soros porton rendelkezésre áll. 
S szégyenszemre, annyi év után a Windows XP eljut oda, 
ahol a Un"xok eddig is elvoltak: teljeskörű felügyelet Telne- 
ten keresztül. Az öszvér neve: Special Administration Conso- 
le. Működni még nem láttam. 


Performance Monitor 

Hány éve várom már annak lehetőségét, hogy DELTA, azaz 
különbségszámlálókat nézegethessek a Performance Monitor- 
ral! Évek óta mondogatom Bill-nek, és most végre hallgatott 
a jó szóra. Eddig ugyanis például semmilyen módon nem le- 
hetett megállapítani egy adott program által felhasznált 
összes memóriát. Érdekes, hogy ezt eddig senki más nem vet- 
te észre rajtam kívül, talán senki nem használ PerfMont? Szé- 
pen vagyunk! Egy szó mint száz, egy processzről meg lehet 
tudni a Working Set méretét, a Pool Nonpaged Bytes-t, meg 
sok egyebet, de ezek közül egyik sem a processz teljes me- 
móriafogyasztása! Ne vitatkozzunk, a Committed Bytes sem 
az! Össze kellene adni a Working Set-et a Pool Paged Bytes- 
sel, de hát ugye erre majd csak a Windows XP lesz képes. 
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0 Már a Professionalban is lesz Terminal Services! 


Automated System Recovery (ASR) 

Visszatér! Ez a feature egyszer már megjelent a Windows 2000 
Beta 3 változatában, de a végleges kódból kivették, mert nem 
készült el hibátlanul a Win2K piacra dobásáig. Miről is van szó? 
Operációs rendszer mentést az élő operációs rendszer segítsé- 
gével, NTBACKUP.EXE-vel szoktunk végezni, s ez nem is zavar 
senkit. Annál zavaróbb, hogy az így készített mentést kizáró- 
lag élő Windows 2000-rel lehet visszatölteni, hisz ki más is- 
merné fel az NTBACKUP által írt szalagot, mint az NTBACKUP?! 
Azaz kell egy oprendszer az oprendszer visszaállításához. Agy- 
rém. Ezt régóta tudjuk, s a fejlesztők réges-régen hozzákezd- 
tek egy olyan megoldás kidolgozásához, amikor a mentés nem 
csak egyszerűen szalagot ír, hanem mellé készít egy bootolha- 
tó csoda-flopit, amiről ha indítunk egy szűz gépet, bekéri a 
szalagot, és feltornássza a gépre az oprendszert. Ez az Auto- 
mated System Recovery, és most bebizonyítom, hogy a Win- 
dows 2000-ben már majdnem benne volt. Az alábbi ábra az 
NTBACKUP-ról készült. Figyeljük meg az ablakot tüzetesen! 





ott biza az ASR hűlt helye. A Beta 3-ban még ott volt. Ipar- 
történeti érdekesség! S hogy honnan tudom? Mert 1998-ban 
Win2K Beta3 tanfolyamokat tartottam az érdeklődő megol- 
dásszállítóknak, és sűrűn dicsértem ezt a feature-t - amíg 
egyszercsak eltűnt. 

Persze be kell vallanom, hogy ezt nem próbáltam ki a Whistler- 
ben, úgyhogy még akármi is lehet, például más funkciója lesz, 
vagy megint kilopják az utolsó pillanatban. Az ASR-re egyelőre 
nem alapoznám a vállalat jövőbeni mentési stratégáját. . . 
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5 Segítség! 


Sok minden jöhet-mehet még Whistler ügyben, a jelenlegi Be- 
ta még csak nem is teljes funkcionalitású, sőt, a funkciókész- 
let terve sem végleges. Éppen döntés előtt áll az a kérdés, 
hogy vajon támogassák-e a NetBEUI és a DLC protokollokat a 
jövőben. Ha új tények merülnek fel a színen, ígérem, 


Folytatjuk. . . 


Fóti Marcell, MCSE, MCT, MCDBA 
Marcellfonetacademia.net 
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Sz Backup - (Untitled] EZ 
Job Edt MWew Iools He 

"Welcome ] Backup] Restore ] Schedule Jobs ] 

Welcome to the Windows 2000 Backup and Recovery Tools 
Backup Wizard 


The Backup vizord helps vot create a backup of you programs and (les so you can prevent dala 
and damage caused by disk falures. power outages, virus infecbons, and other potentialy 





Bestore Wizard 
TŰR BENEZEK Rés taleslzo rek SRAKVSzkesozein eszén sks Bad 
falure, accidental erasure, or other data loss 


Emergency Repair Disk 

This option helps you create an Emergency Riepair Disk that you can use to repair and restart 
"Windows if is damaged. Thiz option does not back up your files or programs, and kis not a 
replacement for regularly backing up your system. 








0 Hol az ASR hűlt helye? 
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Network Monitor A 


(V. rész) 


Az eddigiekben megismerkedtünk a hálózatfigyelés alapjaival, s 
a TCP csatorna felismerése megadta a kulcsot az összes rejtély 
megfejtéséhez, hisz minden izgalmas forgalom TCP csatornában 
zajlik. Ha megvan a csatorna építése és bontása, s ezzel maga a 
csatorna, akkor már , csak" a köztes hálózati forgalmat kell ele- 
meznünk. Ehhez azonban új eszközökre, és a mindenkiben 
szunnyadó matematikai képességek (sőt Boole-algebra!) kiakná- 
zására lesz szükségünk. A dolog nem olyan vészes, mint 
amennyire ijesztő: egyszerű logikai kapcsolatokat fogunk felépí- 
teni a csomagok egyes tulajdonságai alapján, azaz szűrünk. 

De lassan itt az ideje, hogy elszakadjunk az eddigi vizsgálati 
módszerektől is, hisz eddig steril körülmények közt NetMonoz- 
tunk: csak az a hálózati forgalom került a szemünk elé, amit 
valóban szemügyre akartunk venni. A valós életben, amikor a 
Network Monitort hibakeresésre, és egyéb véres dolgokra hasz- 
náljuk, sajnos nincs lehetőség az összes nemkívánatos hálóza- 
ti forgalom elnémítására. Mi több, nemcsak kiszámítható, és 
adott esetben elnémítható hálózati forgalmakkal szembesü- 
lünk, hanem olyasmivel is, ami - csak úgy - egyszer van, egy- 
szer nincs. Ki tudná ugyanis pontosan megjósolni, hogy két 
tartományvezérlő mikor kezd násztáncba, mikor indul el a rep- 
likáció közöttük. 

Megoldás szerencsére majdnem mindig van. Ha a felvételi kö- 
rülmények nem ideálisak, az ügyes nyomozó mindent begyűjt, 
s majd (otthon, a kandalló melegénél) offline szétválogatja az 
értékes nyomokat az értéktelenektől. Ezt az eljárást szűrésnek 
nevezzük. Az igazat megvallva a NetMon képes lenne eleve 
szűrt adatok felvételére, mert futás közben is használhatunk 
szűrőket, de ezzel egyfelől lehet, hogy értékes adatoktól 
fosztjuk meg magunkat, másfelől a futás közbeni szűrők sok- 
kal primitívebbek, mint amit offline használhatunk. 
Érdemesebb talán egy kicsit több memóriát rászánni a feladat- 
ra, s egy kicsivel többet összeguberálni, több szemétben több 
az arany - mondja az ószanszkrit közmondás. A Network Mo- 
nitor memóriában tárolja az elkapott hálózati forgalmat, eh- 
hez induláskor puffert foglal (alapértelmezésben 1 megabáj- 
tot), s a pufferen jár körbe-körbe. 1 megabájt (terhelt hálózat 
esetén) általában kevés, hisz ezen a területen körbe-körbe jár, 
így elég nagy eséllyel felülírja a 30 másodperccel korábban 
rögzített adatokat. Az alábbi ábra azt mutatja, hogyan lehet 
a Network Monitor alapértelmezésben 1 megabájtos memória- 
pufferét megnövelni - mondjuk - tíz megabájtosra. 


tech.net! 














1 Framez 0 
út Frames in Bulfer: 0 
8 Framez lost when 




















.gyter 0 
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5 Növeljük meg a puffert, hisz 1 MB semmire sem elég! 





A fenti ábrán az is megfigyelhető (D, hogy a puffertúlcsordulás 
nem maradna rejtve árgus tekintetünk elől - ha árgus lenne a 
tekintetünk. Én már elemeztem körbefordult hálózati forgalmat. 
Másfél órát rabolt el az életemből ez az apró figyelmetlenség. 


Webböngészés 

Első hálózati forgalmunk a mai alkalommal a http.cap, mely- 
nek tartalma a http://www.netacademia.net letöltése közben 
keletkezett. Ez sem nevezhető különösebben zavarosnak, de 
több TCP csatorna van benne, így minimális szűrőzésre alkal- 
mat ad. Ha letöltik kedves olvasóim az [1] címről, és belete- 
kintenek, valami hasonlót kell látniuk ehhez: 









Microsoft Network Monitor - (Vplatantworktcikkitech.nettaprilisi 


zi kimeie Te Options sie 





































1 EHEHTET 
2 3.935541 — 000001000000 560820000100 
3 4.175880 — 560B20000100 000001000000 TCP 
4 4.175880 — 000001000000 560B20000100 TCP 
5 4.175880 — 000001000000 560820000100 HTTP GET Reguest (from 
6 4.576444 — 560B20000100 000001000000 TCP alksa ese len: [1 
Yi 4.856839 — 560B20000100 000001000000 HTTP Response (to clie 
8 4.906909 — 000001000000 560B20000100 TCP s melles. ÁG a 
9 4.997036 — 560B20000100 000001000000 HTTP Response (to clie 
10 4.997036 — 000001000000 5608B20000100 TCP áélkszérávésg  ÜBIRÚ o 
11 5.137233 — 560B20000100 000001000000 TCP he aAmÉ o 
12 5.137233 — 000001000000 5608B20000100 TCP úlköszsg ÁE o 
13 5.157262 — 000001000000 560B20000100 HTTP GET Reguest (írom 
14 5.537797 — 5608B20000100 000001000000 HTTP Response (to clie 
5.637938 — 560B20000100 —000001000000 HTTP Response (to clieyr 








; 


[EB EEEZBESETTME ETT PSS SA OMEZ 








5 A http.cap tartalma 


Vagyis a SZÖKÉSOS Bone protokoll mellett (mely a Network Mo- 
kat láthatunk, összesen 181 csomagon keresztül. Ugye mostan- 
ra már mindenki tudja, hogy amit HTTP-ként látunk a NetMon- 
ban, az csak az adott csomag lényege, de valójában mind- 
egyik sorunk összetett csomagokat tartalmaz, a HTTP - mint 
tudjuk - TCP-ben utazik, a TCP-t IP szállítja, az IP pedig egy 
Ethernet keret hasznos adata. 
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Szűrési lehetőségek 

Vizsgáljuk meg a NetMon szűrési képességeit! Talán nem lesz 
meglepő, hogy különböző szintek információi alapján képes 
szűrni: kiválogathatjuk egy adott MAC Address hálózati for- 
galmát (az ingyenes NetMon használók eleve csak a saját for- 
galmukat (és a Broadcastokat) látják), egy adott IP című gép 
adatait, valamint protokollok szerint is szűrhetünk. 


Fontos! 

A MAC Address-szintű szűrés félreértésekre adhat okot, hi- 
szen távoli hálózaton lévő gépek esetén nem a távoli gép 
MAC Addressét látom, hanem a Default Gateway hálókár- 
tyájának innenső lábát! 

Miért? 

Mert a MAC Address nem alkalmas végponttól — végpontig 
történő címzésre, erre a feladatra az IP való. A kemény fél- 
rediagnosztizálások elkerülése érdekében szűrjünk inkább 
a feladó és címzett IP címére! 


A NetMon becsapós kettősségének jegyében a szűrés (filter) 
elérhető a főképernyőn is, és az elkapott forgalmak ablakában 
is. A két filter máshol van a menüben, másképp néz ki, és más- 
ra is való! A főképernyős filter (Capture menü-eFilter) egy lé- 
nyegesen kisebb funkciókészletű ablakot hoz elő, melyben a 
futás közbeni szűrőzés beállításait csodálhatjuk meg (de most 
nem használjuk) , míg a forgalmi adatok ablaknál található fil- 
ter (Display menü-Filter) teljeskörű, ámde offline szűrést vé- 
gez, magyarán elrejti/megjeleníti az általunk kiválasztott cso- 
magokat. (Emlékszik még valaki a színezési lehetőségre? Hasz- 
náljuk azt is bátran!) Mielőtt teljesen belemerülnénk, hadd 
hívjam fel a figyelmet az eszközsáv lel gombjára, ezzel 
ugyanis mindig visszatérhetünk a szűrésmentes nézethez, nem 
feltétlenül kell újrainstallálni ehhez az egész Windowst :-) 

A gazdag funkciókészletű filterablak így fest: 


HEAT 








Bi 





TCP:Destination Port zz 1076 
Protocol sz AH 


(AND] 


[En 


fTCP:Source Port sz 1076 
TCP-Destination Port sz 1076 








OR 

















[F Protocol sz AH or ATP or BPDU " 
S ANY €-3 ANY 




















o A teljeskörű filterablak egy bonyolult szűrőkifejezéssel 


Aki ingyenes NetMont használ, az az ablak megnyitásakor fi- 
gyelmeztetésben részesül, hogy nála a szűrés már kissé meg- 
történt, csak a saját gépének forgalmát látja. Ebben az ablak- 
ban - mint azt talán a gombok is sejtetik - hihetetlenül bo- 
nyolult szűrési feltételek adhatók meg, melyeket azután el is 
menthetünk. Most nyomjuk meg az Expression... gombot, 
hogy meglássuk, milyen építőkockákból válogathatunk a bo- 
nyolult logikai kifejezések összelapátolásához: 
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5 Szűrhetünk címekre, protokollokra és egyes bitekre is 


Jól látható, hogy háromféle szűrési lehetőségünk van. 

"2 Az első (Address) fül segítségével MAC Addressre, 

IP és IPX címre, valamint egyéb, a NetMon által felfede- 
zett címekre szűrhetünk. Alapértelmezésben az összes el- 
kapott hálózati forgalmat láthatjuk. (ANYcs-2ANY) 

2 A második (Protocol) fülön választhatjuk ki a megjeleni- 
teni kívánt protokollok listáját. Alapértelmezésben az 
összes előforduló protokoll megjelenített. 

"2 A harmadik (Property) fülön pedig az egyes protokollok bel- 
ső információi alapján is szűrhetünk, ezt néhány bekezdés- 
sel később a TCP csatorna megragadására fogjuk használni. 

A cím szerinti szűrést külön példán nem mutatom be, 
annyira egyértelmű. Lássuk a protokoll szerinti szűrést! Le- 
gyen az első feladat a http forgalom kiszűrése, ennek érde- 
kében kattintsunk a második fülön, ahol a bal panelen lát- 
juk azon protokollok felsorolását, melyek jelenleg átmen- 
nek a szűrőn - azaz mindet. 
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5 Alapértelmezésben az összes protokoll engedélyezett 


Ne sajnáljuk a Disable All nyomógombot, és dobjuk át a dí- 
szes társaságot a jobb oldalra, majd kegyelmezzünk meg a 
HTTP-nek, és azt az egyet kijelölve, nyomjuk meg az Enable 
gombot. Ezzel egy olyan szűrőhöz jutunk, mely csak és kizá- 
rólag a HTTP csomagokat jeleníti meg. Beállításunk eredmé- 
nye így nézzen ki: 
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0 Így már csak a HTTP marad fenn a rostán 


Az OK gomb megnyomása után pedig a helyes filter valami 
ilyesformán alakul (ha nem ezt látják, a szűrés nem ugyanazt 
az eredményt fogja adni, mint nálam, és a későbbiekben nem 
egyről fogunk írni/olvasni): 








Innen csak és kizárólag HTTP Get és Response marad előt- 
tünk, mégpedig egy-egy Get-hez hat-nyolc Response. A 
miértet mindenki tudja: Míg a Get elfér egy csomagban (ma- 
ximum 1514 bájt!), a válasz már ritkán. Nézzük meg a legel- 
ső Get-et (hatodik csomag a 181-ből): 


HTTP: GET Reguest (from client using port 1075) 
HTTP: Reguest Method - GET 
HTTP: Uniform Resource Identifier — / 
HTTP: Protocol Version - HTTP/1.1 
HTTP: Accept — $/r SES] 
HTTP: Accept-Language - en-us 
HTTP: Accept-Encoding - gzip, deflate 
HTTP: User-Agent - Mozilla/4.0 (compatible; 
f MSIE 5.5; Windows NT 5.0; COMt 1.0.2204) 
HTTP: Host - www.netacademia.net 
HTTP: Connection 5 Keep-Alive 
HTTP: Cookie - Language-hu; 

4 ASPSESSIONIDGOGOGBDY-OHOFAODBOJJAHCFNBAJDKAIE 


0 A B jelzésnél olvasható a kért fájl neve, a sima perjel (/) 
utal a default dokumentumra. A default dokumentum a 
mi esetünkben default.asp névre hallgat, és a következő, 
hetedik csomagban kapjuk vissza. Valószínűleg mindenki 
számára ismerős a weblapok letöltődésének menete: első- 
ként egy HTM (vagy ASP vagy egyéb) kiterjesztésű szöve- 
ges fájlt tölt le aböngészőnk, melyből kiolvassa, hogy mi- 
lyen egyéb dokumentumokra lesz még szükség a megjele- 
nítéshez: képekre, stíluslapra stb. Ezeket a további kom- 
ponenseket külön HTTP Get paranccsal szedegeti le szé- 
pen, egyesével, amire bizonyíték a képek későbbi megje- 
lenése, illetve a www.netacademia.net esetében egy ko- 
moly pillanatig stíluslap nélkül látszik az oldal, majd egy 
másodpercre rá megérkezik a stíluslap, és a böngésző át- 
szabja a dizájnt (ez a jelenség csak a legelső látogatóknak 
szúrhat szemet, mert a stíluslapfájl éppúgy bekesselődik, 
mint a többi hasonló adat). Ha a többi Get-et megvizsgáljuk, 
látszik is a letöltés: a 13. csomagban a /css/main.css stílus- 
lap, a 22.-ben pedig az /images/hatter2.gif stb. 
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2 A 8 jelnél láthatjuk a protokoll verziószámát. A HTTP 
1.1-nél tart. Talán a legszembetűnőbb különbség az 1.0 
és az 1.1 között a TCP csatornák újrafelhasználásában 
mutatkozik. Míg az 1.0 minden egyes dokumentum letöl- 
téséhez külön csatornát nyit, s ezzel csomagtömegeket 
indít útjára, addig az 1.1 csak annyi csatornát nyit, 
amennyi a letöltés párhuzamossá tételének érdekében 
szükséges - vagy más szóval annyit, amennyit a sávszé- 
lesség elbír. Minek is nyitna objektumonként külön csa- 
tornát, ha a sávszélesség amúgy sem teszi lehetővé egyi- 
dőben egynél több GIF letöltését? 

-2 Végül a 0 jelre hívnám fel a figyelmet. Itt utazik ugyanis 
az ASP Suli kukija! Az ASPSESSITONIDGOGOGBDY nevű vál- 
tozó csak legelsőre komlett összevisszaság, a türelmes szem- 
lélődő felfedezheti benne az ASP Session ID szavakat. 











Response (to ölést using port 1075) 
Response (to elient using port 1075) 
GET Reguest (from client using port 1076) 
Response (to client using port 1075) 
Response (to elient using port 1075) 
Response (to client using port 1075) 
Response (to elient using port 1076) gi 
Response (to elient using port 1076) 212.97. 926 
GET Reguest (from client usíng port 1076) 2 (6) 
Response (to elient using port 1075) 212.97A24 
Response (to client using port 1075) 212.97.8.36 
Response (to elient using port 1075) 212.97.8.36 
Response (to elient using port 1075) 212.97.8.36 
Response (to elient using port 1075) 212.97.9.36 





5 Az 56K már elegendő sávszélességet biztosít két párhu- 
zamos csatorna megtöltésére 


A fenti ábra 6) jelénél látható, ahogy a böngésző - ki sem 
várva a 1075-ös csatorna eredményét - párhuzamosan útjá- 
ra indít egy másik kérést a 1076-os csatornában. A (6) jelnél 
pedig a csatorna újrahasznosítására látunk példát: a HTTP 
1.1 nem lebontja a dolga végzett csatornát, hanem új felada- 
tot ad neki! Sávszélesség-spórolás: 6 csomag (3 csomag a 
bontásra 4. 3 csomag új csatorna építésére)! Milyen különös, 
hogy a HTTP 1.1 pont akkorra szabadít fel jelentős sávszéles- 
séget, mire az egész sávszélességkérdés röhejessé válik - va- 
lahol Amerikában... 


Hány csatorna van? 
A fenti képernyőképen észrevettünk két csatornát. Ennél 
azonban tudományosabban is megállapíthatjuk, vajon e fájl- 
ban hány különböző TCP csatorna rejtőzik! Egy olyan szűrőre 
volna szükségünk, amely csak a TCP csatornák legelejét, épí- 
tési szakaszát mutatja meg nekünk, s azon könnyedén meg- 
számlálhatjuk, vajon tényleg kettő van-e. Ehhez a szűrőhöz 
bizony már a TCP bitjeire kell szűrnünk, mert a three-way- 
handshake-t (chip-chip-choka) kell elcsípnünk: 

séget 

.A..S. 

allat 
Az S flag egyetlen bit csupán a TCP fejléc Flags mezőjében! 
Ennek kiszűrésére szolgál az Expressions ablak harmadik fü- 
le, ahol le lehet menni - nos, sajnos bitszintre nem. De bájt- 
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szintig mindenképpen. Ahhoz azonban, hogy sikerrel járjunk, 
meg kell állapítanunk a S bájtértékét. Ehhez manuálisan kike- 
resünk egy S csomagot, és onnan kiolvassuk, hogy S-2. A szű- 
rési feltétel ezek után így adható meg: 


Expression 


Expression 
TCP:Flags sz 0x2 


Address ) Protocol  [(Propenty] 


PtotocotPropeny 


















Value ( Byte) 
2 














Acknowledgement Number 
Checksum 

Data dá 
Data Ofíset 
Destination Port 








zi EGT BGBBEZBEZSÉEEBI 
ecrátiné HF TCP-Flags e 0x2 
exists BANY c-3 ANY 














5 Az S, azaz SYNchronize Seguence Number-ek kiszűrése 


A fenti ábra üres helyére odacsempésztem a szűrő logikai 
felépítését, hogy könnyebb legyen ellenőrizni a helyes beálli- 
tást. Az eredmény nem meglepő, két TCP csatornánk van. A 
szűrő két csomagot hagyott meg (ezért e képernyőképet nem 
is mutatom), így sajnos nem látszik a teljes csatornaépítés. 
Azonban ha kilessük a többi lépés bájtkódját is 
....9. z 0X2 
.A..§. 5 0x12 
d z 0x10 
Akkor megfelelő bűvészkedés után majdnem meg is kapjuk 
munkánk gyümölcsét (az ábra közepére varrtam a logikai kife- 
jezést, már OR is van benne!): 
dilEle Edit Display Iools Options Window Help zl8l21 
Sla] :Inl8] SI EBB elt] gel sali] DI 2] 
[rranelrina — [sre mac dar [Dr mac adar [/Droroco1 [Doscriprion — 2] 


z 3.935541 000001000000 560820000100 TCP 
a 4.175880 — 560820000100 000001000000 TCP ak 
a 4-17500  ocgófdlágmákGNENE?  1eT ú o 
7 4.escszs se [AI 50 HTTP Response (to clie 
TEN StE 
9 4.997036 — 5€ [TCP-Flags sz 0x12 30 RTTP 
10 —— 4.997036 OC LTCP Flags ze Ü10 30 TCP 
11 5.137233 5€ SANY €-3 ANY Jo TCP 
12 5.127232 OOVUULUUUUUU — S6USZUUUULOO TCP 
14 —— 5.537797 — 560B20000100 000001000000 HTTP 
15 —— 5.637938 — 560B20000100 000001000000 HTTP (to elie 
16 —— 5.637928 — 000001000000 560B20000100 IC? len: 0 
17 —— 5.738079 — 560B20000100 000001000000 HTTP Response (to clie 
18 —— 5.898205  560820000100 000001000000 RITP Rasponse (to elievl 
HE 


HTTP Protocol Packet Summary FF: 77181 Pr:Z 








































5 Sok bűvészkedés után kevés eredmény: a TCP ,, becsapott"! 


Az ábra tanúsága szerint kétségkívül megfogtuk a three-way- 
handshake-ket - de egy kicsit túl nagyot markolt ez a szűrő. 
Hogy miért? Mert 

mindenütt van! Miközben mi a HTTP-re összpontosítottunk, 
talán el is felejtettük, hogy hűséges rabszolgánk, a TCP a hát- 
térben csatornakarbantartási munkát végez, ACK-ol veszettül 
mindkét irányba! 


Fogjunk meg egy csatornát! 

Végezetül legyen a feladat egyetlen TCP csatorna kiszűrése, 
hisz ez a feladat eléggé mindennapos ahhoz, hogy külön 
megvizsgáljuk. 
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Ha elejétől a végéig meg szeretnénk ragadni a http.cap fájl- 
ból mondjuk a fent említett 1076-os csatornát, akkor port- 
számszűrést kell használnunk. A 1076 ugyanis nem más, mint 
az Internet Explorer által használt kliensport a webkiszolgáló 
elérésére. Mi sem egyszerűbb! Készítsünk filtert a TCP proto- 
koll Source Port mezőjére, ahol a portazonosító 1076! 

Akinek semmi sem maradt a szűrés után, az elvétette a hexa 
- decimális átváltást (2. Akinek azonban így fest az output... 


ISZTELT - old 


ÖÖ Ele Et Display Iools Options Window Help zlojadi 


szB] xIBIs] SI EBET 2[6] lel ali ET 21] 






































SE Sze HAC Adar [/DEc MAC Adar [ Prozosol [/Docczápeion 

12 5.197232 000001000000  560BZO000100 TCP A... len: 0] 

46 Almás a ES tet TS ta Ká §Ú 

sa 9.212972 — 000001000000 560820000100 TCP A. a len: ol 

58 9.813818 000001000000 5608B20000100 TCP ha. a len: o ] 

ú ű 
ÍTCP protocol summary Fz: 87181 [OfE; 4 








5 Szűrés a 1076-os portra. Félsiker. 


. .. az pontosan ugyanazt a hibát követte el, mint én. A MAC 
Address-ből úgy tűnik, sikerült egyirányúvá szűrnünk a forgal- 
mat, amit bizonyít, hogy egy fia HTTP Response nem maradt 
a képernyőn. Mi lehet a baj? 
A tűzfalaknál már szóba került, hogy hányféle forgalom szület- 
het két portazonosító felhasználásával. A hiba oka az, hogy a 
HTTP Response csomagokban nem a feladó portszáma a 1076- 
os (a feladó a 80-as portról a webkiszolgáló) , hanem a címzetté. 
Gyorsan javítsuk ki a szűrési feltételt, és máris miénk a 1076-os 
csatorna teljes forgalma! A helyes szűrőfeltétel így fest: 
BETGEK ESTEKET 


TCP:Source Port sz 1076 
TCP:Destination Port zz 1076 
ANY €-2 ANY 


Elkeserítésképpen 

Végezetül hadd lombozzak le mindenkit: előfordult már a pra- 
xisomban olyan hálózati forgalom, amit nem lehetett szűrés- 
sel különválasztani: egy Windows 2000 tartományvezérlőn 
nem működött az Active Directory keresés LDAP névfeloldása 
(minden más gépen ment), amit igencsak nehezen lehetett 
volna elválasztani a többi LDAP forgalomtól. Meg is gyűlt ve- 
le a bajom! Nincs mit szűrni, ha a DC saját hálózati forgalmá- 
ban, és az Active Directory keresésben is azonos a feladó és a 
célgép IP címe, ráadásul azonos protokollt használnak! Nem 
tehettem mást, lestem, hogy mikor hallgat már el a DC, hogy 
végre az én forgalmam kivehető legyen a csatazajból. 


Fóti Marcell, MCSE, MCT, MCDBA 
marcellf onetacademia.net 


eat Esza ja GATT 


[1] http://technet.netacademia.net/feladatok/netmon 
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A kernel- 
nitektú 

fejlődése 

A Microsoft Windows 2000 számos különböző rétegből épül 
fel, melyek együttesen alkotják az operációs rendszert. A 
rendszer magja a kernel. A kernel nem csupán egy a folyama- 
tok közt, hanem speciális jogosultságokkal rendelkezik a 
hardver fölött. A kernel felelős a memória kiosztásáért az 
egyes folyamatok közt, az eszközkezelőkkel való kommuniká- 
cióért, valamint a folyamatok ütemezéséért. 

Az alkalmazásoknak a kernel biztosítja a működésükhöz szük- 
séges memóriát, processzoridőt, és egyéb hardvererőforráso- 
kat. A Windows 2000 Server kernel a Microsoft Windows NT 4.0 
kernel továbbfejlesztésével jött létre, emez pedig a korábbi 
Windows NT kernelekből származik, ahogy az az alábbi ábrán 


látható. Az újabb verziók mindig a felhasználók, rendszergaz- 
dák és fejlesztők igényeinek figyelembevételével készültek. 


(Windows NT Advanced Server 3-T) 
(Windows NT Server 35) 
(Windows NT Server 40) 
(Windows 2000 Server) 


a A Microsoft Windows 2000 Server számos generáció 
fejlődésének eredménye. 


h 


; 


Amikor a fejlesztőknek olyan funkciókra lett volna szükségük, 
amit a kernel nem tartalmazott, akkor a Microsoft az ő igé- 
nyeiknek megfelelően módosította a kódot. Ilyen eset volt 
például a processzorkvóta és a folyamatszámlálás bevezetése 
az Internet Information Services 5.0 (IIS) rendszerhez. A ker- 
nel most már fejlett többfelhasználós támogatást is tartal- 
maz , mivel lehetővé teszi a Terminálszolgáltatás telepítését - 
nagyobb rendszermódosítás nélkül. 

A Microsoft számos módosítást végzett a kernelen a rendszer- 
gazdák igényeinek megfelelően is, többek közt a Windows 
2000 Server sokkal jobban skálázható mint a Windows NT ko- 
rábbi verziói. A hálózati alkalmazások megbízhatóbban, haté- 
konyabban működnek, mint bármikor korábban. A különböző 
nemzetek felhasználói könnyebben használhatják az alkalma- 
zásokat saját, megszokott nyelvi környezetükben. 

Fontos megérteni a kernelen végzett módosításokat, mielőtt a 
különböző szolgáltatások fejlődését vizsgálnánk. Nagyon sok szol- 
gáltatás fejlesztése szorosan összefügg a kernel módosításával. 


Processzorkvóták és számlálás 

Általános gyakorlat az Internetszolgáltatók körében, hogy 
egyetlen webkiszolgálót sok ügyfél közt osztanak meg. Eddig 
előfordulhatott, hogy egyetlen ügyfél weboldala a processzor 
idejének nagy részét lefoglalhatta, csökkentve a többi ügyfél 
oldalának teljesítményét is. Hasonló módon, egyetlen fel- 
használó rosszul megírt ASP kódja a teljes intranetkiszolgálót 
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használhatatlanná tehette. Hiába volt képes az IIS a sávszé- 
lesség szabályozására, ha maga az operációs rendszer képte- 
len volt az egyes weboldalakra jutó processzoridőt korlátozni. 
Két új lehetőség segít a többfelhasználós rendszerek hatéko- 
nyabb kihasználásában: a processzoridő számlálása és annak 
szabályozása. A processzoridőszámlálást az IIS alkalmazza an- 
nak rögzítésére, hogy az egyes webkérések mennyi procesz- 
szoridőt vesznek igénybe. Ez lehetővé tesz a processzor hasz- 
nálat alapján történő számlázást, továbbá a fejlesztőket is se- 
gíti annak kiderítésében, hogy melyek azok az oldalak, ahol 
az optimalizálás különösen hasznos lehet. 

A technológia, ami a fenti két funkciót lehetővé teszi, a mun- 
kaobjektum. Hogy megérthessük miként működik egy munkaob- 
jektum, vizsgáljuk meg, hogy az alkalmazások és szolgáltatások 
miként használják a folyamatokat. A szolgáltatások (mint pél- 
dául az IIS) sok folyamatot indítanak el annak érdekében, hogy 
a különböző feladatokat egyszerre tudják végrehajtani. Míg a 
sok folyamat alkalmazása növeli a teljesítményt, ugyanakkor ne- 
hezebbé teszi annak megállapítását, hogy melyik folyamat me- 
lyik feladathoz tartozik. Mivel az IIS 4 támogatja azt, hogy a vir- 
tuális kiszolgálók közös memóriaterületet használjanak, szinte 
lehetetlen megállapítani vagy szabályozni, hogy az egyes virtuá- 
lis kiszolgálók mennyi erőforrást használhassanak. 

A munkaobjektum lehetővé teszi azt, hogy az operációs rend- 
szer az egy csoportba tartozó folyamatokat egyetlen egység- 
ként kezelje. Ezáltal sokkal egyszerűbb az alkalmazásokhoz 
tartozó erőforrások használatának figyelése és szabályozása. 
Ez különösen fontos olyan esetekben, amikor több ügyfél 
használja ugyanazt a kiszolgálót. 


Spinszámlálás 

A spinszámlálás egy olyan eljárás, ami többprocesszoros rend- 
szerek teljesítményét növeli olyan esetekben, amikor több 
program kívánja ugyanazt az erőforrást egyszerre használni. A 
spinszámlálás határozza meg, hogy egy folyamat hányszor pró- 
báljon egy erőforrást használni, mielőtt várni kezdene. Például 
nézzünk egy alkalmazást, ami egyszerre több lekérdezést futtat 
több processzoron. Az első lekérdezés megpróbál írni egy adott 
tábla adott sorába, de nem tud, mivel a második lekérdezés zá- 
rolta azt a sort. Spinszámlálás nélkül az első lekérdezés vár egy 
ideig, blokkolva a lekérdezés végrehajtását. Spinszámlálás al- 
kalmazásával az első lekérdezés egyszerűen újra megpróbál írni 
az adott sorba néhány alkalommal annak reményében, hogy a 
második folyamat gyorsan megszünteti a .zárolást, és csak ak- 
kor fog várni, ha ezek a kísérletek sikertelenül végződnek. 

Ez csak többprocesszoros rendszerekben hasznos, ott ugyanis 
egyszerre több folyamat futhat. Egyprocesszoros rendszeren a 
különböző folyamatoknak mindenképpen várniuk kell egymás- 
az azt blokkoló másik folyamat meg nem kapja a vezérlést. Az 
egyprocesszoros rendszeren futó spinszámlálós alkalmazások 
nem lesznek lassabbak - csupán nem futnak majd gyorsabban. 
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Scatter/Gather [/D 

A Scatter/Gather I/O rendszer a Windows 2000 Server olyan 
újdonsága, ami a hálózatban lévő alkalmazáskiszolgálók tel- 
jesítményét javítja. Ennek használata az rendszergazda szá- 
mára sem látható, mivel az alkalmazások minden további kon- 
figurálás nélkül képesek használni. A technológia lehetővé te- 
szi, hogy a memóriában elszórtan elhelyezkedő adatokat a le- 
mezre folyamatosan lehessen kiírni. Az alkalmazásokat fel kell 
készíteni ennek használatára, ezért a jelenlegi alkalmazások 
működését ez a módszer nem javítja. 

Ez a technológia először a Windows NT rendszerhez kiadott 
service pack csomagban jelent meg, speciálisan a Microsoft 
SOL Server teljesítményének javítására. A Windows 2000 Ser- 
ver az első olyan Microsoft operációs rendszer, ami ezt a tech- 
nológiát alapfunkcióként tartalmazza. 


Időzítők 

Az időszelet a szálak egy jellemzője, ami azt határozza meg, 
hogy az adott szál mennyi ideig futhat, mielőtt a vezérlés a 
következő szálra kerülne. Mivel a környezetváltás bizonyos 
időt vesz igénybe, egyes alkalmazásoknál előnyös lehet a 
kvantumidőt megnövelni, habár ettől a rendszer többfelhasz- 
nálós teljesítménye csökkenhet. 

A kvantum típusa lehet fix vagy változó hosszúságú. Ezt a 
Performance Options párbeszédablakban lehet beállítani, ami 
a System Properties ablak Advanced fülénél található. 
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5 Megadhatjuk a kvantumok típusát és hosszát. 











Az alkalmazásoknak adott magasabb prioritás rövid, változó 
hosszúságú kvantumot, és sima, gördülékeny többfelhaszná- 
lós működést eredményez. A háttérben futó szolgáltatások 
prioritását emelve hosszú, fix kvantumokat kapunk, ami a há- 
lózati szolgáltatások teljesítményét javítja. Alapértelmezés 
szerint a Windows 2000 Server a háttérben futó szolgáltatá- 
soknak, a Windows 2000 Professional pedig az alkalmazások- 
nak ad nagyobb prioritást. 


Windows Driver Model 

A meghajtó egy olyan program, melynek segítségével az ope- 
rációs rendszer kommunikál egy hardvereszközzel. A különbö- 
ző videókártyák különböző képességekkel bírnak, és különbö- 
ző módon kommunikálnak; a meghajtó végzi a , fordítást" a 
Windows 2000 és a videókártya között. Minden hardverhez 
szükség van meghajtóra: hálózati kártyákhoz, SCSI vezérlők- 
höz, modemekhez éppen úgy mint lapolvasókhoz vagy nyom- 
tatókhoz. A Windows korábbi verziói különböző meghajtókat 
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igényeltek minden operációs rendszerhez. Ez mind a meghaj- 
tókat író hardvergyártóknak, mind a rendszereket karbantartó 
rendszergazdáknak komoly munkát jelentett. 

Az új Windows Driver Model (WDM) lehetővé teszi hogy a Win- 
dows 2000 és a Windows 98 rendszerek ugyanazt a meghajtót 
használják. Ez előnyös a hardvergyártóknak, mert nem kell két 
különböző meghajtót fejleszteniük. Előnyös a felhasználók- 
nak, mert növeli a Microsoft rendszerek kompatibilitását. 

A WDM-nek további előnyei is vannak. A Microsoft a meg- 
hajtóprogramok írásához szükséges munka nagy részét elvé- 
gezte. A hardvergyártóknak továbbra is kell írniuk egy kis 
minimeghajtót a termékeikhez, de ez lényegesen kevesebb 
programozói munkát igényel. 

A WDM Kernel Streaming architektúra a valósidejű streaming 
anyagok teljesítményét növeli. A Windows előző verzióiban a 
streaming alkalmazásokhoz szükséges számítások nagy részét 
az alkalmazások felhasználói módban (user mode) végezték. 
Ezen műveletek nagy része most kernel módban fut, ami sok- 
kal gyorsabb működést eredményez. Az alkalmazásokat fel 
kell készíteni a WDM Kernel Streaming használatára, ezért a 
régebbi programok nem profitálnak ebből a megoldásból. 

A WDM Still Image architektúra operációs rendszer szintű tá- 
mogatást nyújt lapolvasók és digitális kamerák alkalmazásá- 
hoz. Ennek révén a felhasználók egy egységes, integrált felü- 
letet kapnak a lapolvasók és fotóeszközök egységes kezelésé- 
hez. A Windows korábbi verzióiban a hardver fejlesztőjének 
kellett arról gondoskodnia, hogy az eszköz megfelelően 
együttműködjön az operációs rendszerrel. 


Entreprise Memory Architecture (EMA) 

A memóriakiosztás sok nagy alkalmazáskiszolgálónál jelent- 
het szűk keresztmetszetet. Ez különösen igaz az akár több 
száz gigabájt adat kezeléséért felelős adatbáziskiszolgálóknál. 
A Windows 2000 Server egyik újítása az Entreprise Memory Ar- 
chitecture (EMA), melynek segítségével 32 bites processzo- 
rokkal akár 64 GB memória kezelése is lehetséges. A legtöbb 
kiszolgáló nem igényel ennyi memóriát, de bizonyos adatban- 
koknál ez hasznos lehet, hiszen a memóriában lévő adatokkal 
sokkal gyorsabban lehet műveleteket végezni, mint a merev- 
lemezen lévőkkel. Nem minden rendszer képes ennyi memória 
kezelésére, de az Alpha és Pentium II Xeon processzorok már 
ma is ki tudják ezt használni. 

Az alkalmazásokat fel kell készíteni a VLM (Very Large Memory) 
API használatára. A Microsoft SOL Server erre már fel van ké- 
szítve, és minden bizonnyal a többi relációs adatbáziskezelő- 
bőlis készül majd ilyen verzió. A legtöbb alkalmazásnak azon- 
ban nincs szüksége 4 GB-nál nagyobb memóriára. 


Hatékonyabb többprocesszoros működés 

Azon kiszolgálóknál, ahol a processzorteljesítmény jelenti a szűk 
keresztmetszetet, a Windows 2000 Server továbbfejlesztett több- 
processzoros támogatása nagy előnyt jelenthet. Bár a Windows 
NT mindig is támogatta a többprocesszoros rendszereket, az 
új generációs kiszolgáló program ezt még hatékonyabbá teszi. 
Valamennyi többszálú alkalmazás gyorsabban fut többprocesszo- 
ros rendszeren, s ehhez nem kell alkalmazáskódot módosítani. 
A Windows 2000 Server négy processzor egyidejű használatát 
támogatja. Akik pedig Windows NT 4.0 Server Enterprise Edi- 
tion rendszerüket cserélik Windows 2000 Advanced Server 
rendszerre, továbbra is legfeljebb nyolc processzort használ- 
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hatnak. A Windows 2000 Advanced Server megduplázza az 
eddig használható processzorszámot - akár 8 processzor 
egyidejű használatát is támogatja. A hardvergyártóktól akár 
32 processzoros rendszerek is rendelhetők. 

Elsőként a Windows operációs rendszerek közt, a folyamatokat 
egy kijelölt processzorhoz lehet rendelni. A rendszergazda a Task 
Manager segítségével beállíthatja a folyamatok processzoraffini- 
tását. Ekkor a folyamat csak a kijelölt processzoron fog futni, ez 
növelheti a teljesítményt, mivel csökkenti a cache területek 
kiürítésének/feltöltésének számát, ami a processzorokon futó 
különböző folyamatok miatt szükségessé válhat. Óvatosan kell 
ezzel a lehetőséggel élni, hiszen akár a rendszer teljesítményé- 
nek csökkenését is eredményezheti, mivel a folyamat ekkor nem 
kerülhet másik, esetleg kevésbé foglalt processzorra. 


120 Támogatás 

Az I20 (Intelligens I/O architektúra) egy új technológia, mely 
egyidejűleg csökkenti a processzor terheltségét, és növeli a 
rendszer [/0 teljesítményét. Az I20 használatakor egy külön, 
dedikált processzor felel az I/0 műveletekért. Ez különösen a 
nagy sávszélességigényű alkalmazásoknál hasznos (valóside- 
Jjű audió- és videóalkalmazások) . 


Rendezési alapritmusok 

Nagy adatbázisrendszerek esetén lesz különösen hasznos a 
Windows 2000 Advanced Server továbbfejlesztett rendezési 
modellje. Ezek teljesítménye nagyban megnőtt, mivel az 
ezekhez szükséges processzorigényes algoritmusok most már 
kernel módban futnak. Az alkalmazásokat fel kell készíteni 
ezen új API használatára (a Microsoft SOL Server legújabb ver- 
ziója már támogatja ezt). 


A Zero Administration for Windows támogatását 

szolgáló módosítások 

A Plug and Play rendszer révén a rendszergazdáknak kevesebb 
időt kell tölteniük hardverek konfigurálásával és hibajavítással. 
Az Advanced Configuration and Power Interface (ACPI) haté- 
konyabb energiakihasználást tesz lehetővé, ezáltal csökkentve 
a fenntartási költséget. A lemezkvóták segítségével könnyeb- 
ben kézben tartható a lemezterület. A távoli rendszerindítás se- 
gítségével a munkaállomások telepítése jelentősen felgyorsul. 


Plug and Play 

A számítógéphálózatok felügyeletének egyik legproblémá- 
sabb területe a hardverkonfigurálás. Régebben a hardver he- 
lyes beállításához elengedhetetlen volt a megszakítások, I/O 
portok és a Direct Memory Access (DMA) rendszer ismerete. 
A Plug and Play technológia segített ezen folyamatot egy- 
szerűsíteni, de nem támogatta minden operációs rendszer. A 
Windows 95 és a Windows 98 teljes mértékben támogatta ezt 
a protokollt, de a Windows NT 4.0 csak minimális mértékben. 
A Windows 2000 Server jobb Eszközkezelővel és Hardverva- 
rázslóval rendelkezik mint bármelyik korábbi Windows verzió. 
Ezek ez eszközök megbízhatóan felismerik és feloldják a 
hardverkonfliktusokat. Ez a kiszolgáló rendelkezésre állási 
idejét is javítja, mivel a rendszergazdának nem kell hosszú 
időt eltöltenie az újonnan telepített hálózati kártya, modem 
vagy merevlemez beállításával. 
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9 Az eszközkezelő (Device Manager) segíti a rendszergaz- 
da munkáját a hardverbeállításoknál. 


Amikor az operációs rendszer elindul, automatikusan felisme- 
ri az új hardvert, és amikor egy rendszergazda bejelentkezik, 
elindítja a Hardvervarázslót. A legtöbb konfliktust a rendszer 
automatikusan észreveszi és feloldja, azon esetekben pedig, 
amikor a rendszergazdának manuálisan kell beavatkoznia, 
munkáját könnyen elérhető online súgó segíti. 


OnNow/ACPI 

Az OnNow/ACPI technológia az energiafelhasználás hatéko- 
nyabb vezérlését segíti. Ez főként a hordozható gépek tulajdo- 
nosainak fontos, a kiszolgálóknál általában nem annyira fontos 
szempont, hogy a gép mennyi energiát fogyaszt. Ezek a szab- 
ványok be vannak építve a Windows Driver Model rendszerébe. 
Ezért mind a Windows 2000 Server, mind a Windows 2000 csa- 
lád többi tagja éppen úgy támogatja, mint a Windows 98. 


Lemezkvóták 

A Windows új verziójával lépett színre az NTFS fájlrendszer új 
verziója is. Egyik legérdekesebb újítása a felhasználók által hasz- 
nálható lemezterület korlátozásának lehetősége, melyről e lap- 
számban részletes cikket is olvashat. Ez lehetővé tesz hogy a fájl- 
és webkiszolgálók rendszergazdái pontosan kézben tarthassák 
a felhasználók által tárolt fájlokat. Lehetőség van úgy beállítani 
a rendszert, hogy a felhasználók ne tölthessék meg a partíciót! 


Távoli Rendszerindítás 

A Windows 2000 Server új távoli rendszerindítása egyszerűb- 
bé teszi a munkaállomások bekapcsolásának irányítását. Míg 
a kiszolgálók általában folyamatosan üzemelnek, a munkaál- 
lomásokat hasznos lehet munkaidőn kívül kikapcsolni. A köz- 
ponti kiszolgálóról szabályzott rendszerindítás lehetősége a 
konfigurálást is egyszerűsíti, hiszen nem kell minden géphez 
egyesével odamenni. 

Természetesen a hálózati kártyákat és azok meghajtóit fel 
kell készíteni a távoli rendszerindítás kezelésére. Az új kár- 
tyák képesek az indítási kérelmek fogadására, akár a gép ki- 
kapcsolt állapotában is. A Microsoft dolgozik ezen funkció 
szabványosításán, és saját rendszereiben támogatja is. 
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Fürtözés 

A hálózatukat intenzíven használó szervezeteknél a magas 
rendelkezésre állás alapkövetelmény. A leállás a magas fenn- 
tartási költség egyik legfontosabb okozója. Ez számos külön- 
böző okból bekövetkezhet: 

"0 Hardverhibák 

"I Alkalmazáshibák 

"0 Konfigurálás miatti újraindítások 

"B Frissítések és javítások 

A Windows 2000 Advanced Server fürtözési eljárása lehetővé 
teszi hogy két kiszolgáló egymást helyettesítse. Ha az egyik 
kiszolgáló leáll, a másik egy percen belül automatikusan át- 
veszi a helyét. A figyelőszolgáltatások érzékelik a hibát, és a 
kéréseket a második kiszolgálóhoz irányítják. 

Tervezett leállásoknál egy kiszolgáló átveheti a másik felada- 
tait, amíg az nem elérhető. Ezen folyamat révén minimális 
lesz a javítások miatti leállás. Ez leginkább a rendszergazdák 
munkáját segíti, hiszen így a legújabb javítások és frissíté- 
sek telepítéséhez nem kell megvárniuk a munkaidő végét! 
(Nono. Azért az erőforrások átmozgatása nem vértelen folya- 
mat! A nyitott kapcsolatok megszakadnak, az el nem mentett 
munka elvész stb. — a szerk.) 

A fürtözés másik célja a terhelés minél egyenletesebb elosz- 
tása több gép közt. Bár a Microsoft fürtözési technológiájá- 
nak elsődleges célja a rendelkezésre állás javítása, használha- 
tó terhelés-kiegyenlítésre is. Például a fájl- és nyomtatómeg- 
osztások több rendszer közt lehetnek tükrözve. A kéréseket a 
rendszer automatikusan elosztja két vagy több rendszer közt, 
és az ügyfelek egy kiszolgáló leállása esetén automatikusan 
másikat keresnek a fürtben. 

A fürtözés magába az operációs rendszerbe beépített szolgál- 
tatás. A fürtöket egyszerű felügyelni, mivel az adminisztrációs 
eszközök segítségével több kiszolgáló beállítása végezhető el 
egyidőben. Sok külső megoldással ellentétben a Windows 
2000 Advance Server nem igényel mindehhez drága vagy 
egyedi hardvert. A Windows 2000 Advance Server fürtözési 
képességét mindenféle speciális eszköz nélkül, azonnal hasz- 
pek is lehetnek, például egy kevésbé drága gép is lehet biz- 
tonsági kiszolgáló. (Azért egy NetAcademia fürttanfolyam nem 
árt, mielőtt belevetjük magunkat. — a szerk.) 

Számos további szolgáltatás is ismeri már a fürtözést: 

"2 WINS (Windows Internet Name Service) 

"8 DHCP (Dynamic Host Configuration Protocol) 

"8 Dfs (Distributed File System) 


Terminálszolgáltatás 

A Windows 2000 Server az első olyan Windows operációs 
rendszer, ami beépített terminálszolgáltatással rendelkezik. 
Ez lehetővé teszi, hogy az ügyfelek interaktív alkalmazásokat 
futtassanak egy távoli kiszolgálón. Az ügyfél rendszere fogad- 
ja a bementi adatokat és megjeleníti az eredményeket a fel- 
használó képernyőjén. Az ügyfél gépe és a kiszolgáló közt az 
adatok a hálózaton közlekednek. Minden feldolgozás a kiszol- 
gálón történik. 
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Billentyűleütések és 
egérmozdulatok 


A Treminál Services 
futtatja a felhasználó 
alkalmazásait 


H 


o A Terminálszolgáltatás tehermentesíti a munkállomáso- 
kat, mivel az alkalmazások a kiszolgálón futnak 


Képernyőkép 


A vékony ügyfél (thin client) olyan munkaállomás, ami csak 
minimális számú alkatrészt tartalmaz. Ahelyett, hogy a mun- 
kaállomásokba gyors processzort, sok memóriát és nagy me- 
revlemezt vásárolnánk, a hálózati Terminálszolgáltatás végzi 
a munka zömét. A vékony ügyfél egyszerűen továbbítja a ké- 
réseket a kiszolgálóhoz. A felhasználó továbbra is egy jól fel- 
szerelt munkaállomást érzékel. Az ügyfélgépek hardverköve- 
telménye minimális, a Terminálszolgáltatás bármilyen munka- 
állomással jól használhatóak. 

A kliensekre vonatkozó alacsony követelmények különösen 
hasznosak lehetnek régebbi gépparkkal rendelkező vállalatok 
esetében. A meglévő Windows for Workgroups 3.11 és Win- 
dows 95 rendszerek az operációs rendszer cseréje nélkül ké- 
pesek ügyfélként működni. Ennek segítségével egy korosabb 
munkaállomás is képessé válik a legújabb 32 bites alkalmazá- 
sok használatára, ami növeli élettartamát. Természetesen a 
Windows 2000 Server tartalmazza a terminálügyfélprogram 
telepítőjét Windows NT 4.0, Windows 95, Windows 98, és 
Windows 2000 Professional rendszerekhez is. 

Mivel a kiszolgáló végzi a feldolgozás nagy részét a hálózatban, 
a Terminálszolgáltatás erősebb hardvert igényel. Ez a többlet- 
költség azonban megtérül az olcsóbb munkaállomások vásárlá- 
sakor. Ez az architektúra további költségcsökkentő tényezőket 
is tartalmaz. Az alkalmazások magán a kiszolgálón helyezked- 
nek el, így a rendszergazdáknak is kevesebb a munkájuk ha va- 
lamit módosítani kell. A felhasználói környezet is jobban kéz- 
ben tartható, mivel teljes egészében a kiszolgálón található. 
A Windows 2000 Server kernelének tervezését számos helyen 
befolyásolták a Terminálszolgáltatás szükségletei. Korábban a 
Windows operációs rendszerek egyetlen interaktív folyamat 
futtatására voltak felkészítve, azon folyamatéra, amit a gép 
előtt ülő felhasználó futtatott. Annak érdekében, hogy a háló- 
zaton keresztül futtatott több interaktív folyamat helyesen 
működjön, a Windows 2000 egy erősen módosított Win32 al- 
rendszert használ. Ez az új alrendszer képes a különböző alkal- 
mazásokat egymástól függetlenül követni és tárolni. A billen- 
tyűzet- és egérparancsok nemcsak az adott alkalmazásra, de a 
felhasználó teljes munkakörnyezetére vonatkoznak. Minden 
felhasználóra a saját biztonsági megszorításai érvényesek. Te- 
chikailag egy külön Win32 folyamat kezel minden felhasználói 
kapcsolatot. Ez biztosítja azt, hogy az alkalmazások nem kom- 
munikálnak a felhasználói kapcsolatok közt, ami megakadá- 
tyozza a felhasználói jogok megsértését. A kernel ezen módo- 
sításai nincsenek hatással azon rendszergazdák munkájára, 
akik nem kívánják használni a Terminálszolgáltatást. 


tech.net! 


WINDOwS 2000 


Globalizáció 

Az eredeti Microsoft operációs rendszerek az Egyesült Álla- 
mok vevőközönségének készültek. Csak a Latin ábécét tartal- 
mazták, és az angol nyelvű szövegeket támogatták, és nem 
tartalmaztak olyan segédeszközöket, amik a nemzeti nyelvű 
alkalmazások támogatták volna. Mivel a Windows iránti 
igény a világ többi részén is felmerült, a fejlesztők más or- 
szágok számára is készítettek alkalmazásokat. Ez a fejlesztés 
nehézkes volt, hiszen az operációs rendszer maga nem volt 
ilyen használatra felkészítve. Az újabb Windows verziók ezért 
egyre több módon támogatták a más nyelvű felhasználókat, 
és a nekik alkalmazást készítő fejlesztőket. A Windows 2000 
operációs rendszer tartalmazza valamennyi Windows közt a 
legtöbb globalizációt segítő eszközt. 

A Windows 2000 kernel speciálisan a globális igények kielé- 
gítésére lett felkészítve. Unicode karaktereket használ ma- 
ga a rendszer is, ami nagyban egyszerűsíti a nemzeti ver- 
ziók elkészítését. Az NLS, a Native Language Suport lehető- 
vé teszi a helyi és nyelvi információk rögzítését a rendszer- 
leíró adatbázisban, amire építve a felhasználói felület en- 
nek megfelelő felületet kínál(hat). Ezek révén a fejlesztők 
nemzetközi környezetben is helyesen működő alkalmazáso- 
kat fejleszthetnek, a felhasználók pedig még jobban testre- 
szabhatják munkakörnyezetüket. 


Unicode betűtípusok? 

A Unicode majdnem 40,000 karaktert kódol. Nincsen olyan 
betűtípus, ami valamennyit képes lenne megjeleníteni. A kü- 
lönböző betűtípusok a Unicode karakterkészlet különböző ré- 
szeit támogatják, így az egyes nyelvek megjelenítéséhez to- 
vábbra is helyi betűtípusok telepítése szükséges. 

A Windows 2000 támogatja a Unicode karakterkészletet, és 
az operációs rendszer mindenhol ezt használja. Például va- 
lamennyi NTFS fájlnév Unicode karakterekből áll. Ez lehe- 
tővé teszi ugyanazon fájlrendszer használatát bármilyen 
nyelvi környezetben. Az alkalmazásokat fel lehet készíteni 
a Unicode által nyújtott előnyök kihasználására, de ezt 
nem minden alkalmazás igényli. 
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Native Language Suport (NLS) 

Az NLS lehetővé teszi, hogy a rendszergazda az operációs 
rendszert helyspecifikus információk figyelembe vételével 
állítsa be. Az API a Windows NT első verzióitól kezdve az 
operációs rendszer része. Ez közel száz beállítás rögzítését 
jelenti a rendszerleíró adatbázisban, és biztosítja az ezekhez 
való hozzáférést, így az alkalmazások egyszerűen meghatá- 
rozhatják az adott rendszeren érvényes helyi beállításokat. 

A helyspecifikus beállítások többet jelentenek a felhasználó 
által preferált nyelv rögzítésénél. A különböző országok kü- 
lönböző formában jelenítik meg a dátumokat, időket, a hét 
napjait, a pénzt, és még számos egyéb információt. Szabvá- 
nyos API-k használatával a felhasználónak nem szükséges 
minden egyes alkalmazásnál beállítania ezeket a jellemzőket. 
Az operációs rendszert egyszer kell beállítani, ezután minden 
alkalmazás lekérdezheti a rendszer beállításait. 

Csak az adott nyelvhez és országhoz szükséges fájlok kerül- 
nek telepítésre. Ezek helyigénye sokkal kisebb ahhoz képest, 
ha valamennyi a Windows 2000 által támogatott nyelvhez 
tartozó fájl telepítésre kerülne. 


Összegzés 

A kernel a Windows NT Advanced Server 3.1 architektúrájá- 
hoz hasonló alapokra épül, a modern hálózati igények kielé- 
gítéséhez szükséges módosításokkal. A kernel révén az ope- 
rációs rendszer jobban skálázható, 32 processzor és 64 GB 
memória használatát támogatja. Lehetővé teszi hogy adatbá- 
zisrendszerek, mint például a Microsoft SOL Server kihasznál- 
hassák az erősebb hardvert, és a sebességkritikus részek ker- 
nelbe integrálásával tovább növeli azok teljesítményét. A 
processzorkvóták és a folyamatszámlálás a Windows 2000 
Servert ideális rendszerré teszik webes kiszolgálószerepre. A 
most már kernelbe integrált fürtözési lehetőség a redundáns 
hálózatok rendelkezésre állási idejét növeli. Végül, de nem 
utolsó sorban a Windows 2000 Server rendelkezik valamennyi 
Windows operációs rendszer közt a legrugalmasabb nyelvi és 
nemzeti támogatással. 
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WINDows 2000 


Áttérünk, áttérünk. Windows 2000-re. Először a tartományve- 

zérlőkön, mert azokból kevés van. A munkaállomások ráérnek! 

Sok vállalat jutott már el a Windows 2000 áttérés azon szaka- 

szába, amikor fontolóra veszik a tartomány átállítását Mixed 

módról Native módra. Ilyenkor szembesülnek azzal, hogy a két 

üzemmód közötti különbség eléggé homályosan dokumentált, s 

a helyzetet csak rontja, hogy különböző legendák és babonák 

keringenek a neten a Natív mód kegyetlenkedéseiről. Az izguló 

rendszergazda ezeken a kérdéseken rágódik hetekig: 

-0 Lesz-e NetBIOS támogatás? 

Mi lesz a PDC emulátorral? 

Lesz-e továbbra is NTLM hitelesítés, vagy csak Kerberos marad? 

Képesek lesznek-e régi operációs rendszereink felvenni a 

kapcsolatot a Native módú tartománnyal? 

Fognak-e működni a régi típusú házirendek 

(NTCONFIG. POL)? 

A fordítottjára is láttam példát, hisz töprengésre adhat okot az is, 

hogy mi VAN Mixed módban, hisz az nem , olyan jó" üzemmód: 

2 Vajon DNS-t használnak a Windows 2000 Pro kliensek a 
tartományvezérlő megtalálására? 

0 Van Kerberos? 

2 Megtalálják-e a munkaállomások, hogy melyik telephelyre 
tartoznak? 

Hovatovább oda jutottunk, hogy a babonák nagyobb súllyal es- 

nek latba a döntés meghozatalakor, mint a tudomány, s e kö- 

zépkori gondolkodás miatt általában a Native módra történő 

átállás el is marad. Pedig mi mindent nyernénk! 

De kezdjük a történetet az üzemmódok elemzésével, s ez remé- 

nyeim szerint eloszlat egy-két tévhitet. 
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Kompatibilitás 

A Windows 2000-re történő áttérés nem okozhatja a régi, beve- 
zetett rendszerek működésképtelenné válását, hisz ha így történ- 
ne, bizony senki még csak meg sem fontolná a frissítést. Mi min- 
denre kell gondolnia Redmondnak, ha vadonatúj operációs rend- 
szerének kompatibilisnek kell maradnia a régi termékekkel! Fut- 
nia kell a régi szoftvereknek, a régi munkaállomásoknak csatla- 
kozniuk kell az új tartományhoz, és - hogy a vállalati címtár tar- 
talma külön erőfeszítés nélkül átkerüljön az új rendszerbe - meg 
kell tudni upgradelni a tartományvezérlőket. Támogatni kell a va- 
donatúj protokollok (IPSec) mellett a régieket is (NetBIOS). Ke- 
mény feltételek ezek! Ezért is gondolják sokan, hogy ez csak 
ideig-óráig tartható, de előbb-utóbb eljön az igazság pillanata, s 
a régi vackokkal le kell számolni. Noha ez így igaz, alapvető té- 
vedés azt hinni, hogy a Native módra történő átállás okozná ezt 
a kompatibilitási törést. Ugyanis a Mixed és Native üzemmódok- 
nak semmi közük a végfelhasználói rendszerekkel történő kap- 
csolattartás kompatibilitási szintjéhez. Ha az előbbi kérdéseket 
megismételném (van-e NetBIOS, WINS stb. Native módban), az 
lenne rá a helyes válasz, hogy van bizony, hisz ezek ügyfélhoz- 
záférési technológiák, melyek elérhetők mindkét üzemmódban. 
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Mixed vs. Native 


Akkor hát mi a Native üzemmód? 

Van köze a kompatibilitáshoz, de más szinten. Ha összehason- 
ttjuk a Windows NT , címtárát", a SAM-ot és az Active Directo- 
ry-t, látunk néhány lényeges különbséget. Az AD hierarchikus, 
míg a SAM kétdimenziós. Az AD-ban bővíthető sémájának kö- 
szönhetően tetszőleges objektum tárolható, a SAM-ban csak 
olyasmi, amit a SAMDRV.DLL lehetővé tesz: felhasználók, cso- 
portok, számítógépek (Computer Account) . Az AD-ban a repliká- 
ció alapegysége a piciny attribútum, a SAM-ban a user. Az AD- 
ban több százmillió objektum tárolható, a SAM-ban maximum 
negyvenezer. A SAM-okból csak egyetlen példány módosítható 
(a Primary Domain Controller példánya írható/olvasható, míg a 
Backup Domain Controlleré csak olvasható), az Active Directory- 
nál mindegyik tartományvezérlő írható másolatot tárol a címtár- 
ból. Az Active Directory lehetővé tenné, hogy azonos típusú cso- 
portokat ágyazzunk egymásba (globálist globálisba), a SAM ezt 
nem viseli el. Az AD-ban létezik egy olyan csoporttípus, amely 
még a Global-nál is globálisabb, ez a Universal típusú csoport - 
no ezt sem nyeli le a SAM. Olyan súlyos különbségek ezek, hogy 
szinte lehetetlenné teszik a régi és az új együttélését. A szaba- 
don szárnyaló Active Directory-t gúzsba kell kötni ahhoz, hogy 
régi típusú Backup Domain Controllerekkel együtt tudjon mű- 
ködni. Na ezt hívják Mixed módnak. 


Mixed mód 

Mixed módban lehetőség van arra, hogy egy tartományban ve- 
gyesen használjunk Active Directory tartományvezérlőket és NT4 
BDC-ket (PDC-t nem mert az nem tűr meg még egy dudást a csár- 
dában, márpedig az Active Directory egy dudás, hiszen definíció 
szerint írható címtárkópiával rendelkezik). Mixed módban az Ac- 
tive Directory csak olyan adatot fogad be a módosítások alkal- 
mával, amit vagy nem is kell ,lejelentenie" a BDC-knek, mert 
SAM nem ismeri őket (például címtárba publikált nyomtatóobjek- 
tumok), vagy ha oda kell adnia a BDC-knek, akkor képes legyen 
rá. Azaz a hierarchia kisimítható legyen (ennek feltétele, hogy 
minden objektum egyedi SamAccountName tulajdonsággal rendel- 
kezzen), ne legyen több, mint negyvenezer, ne legyenek Univer- 
sal csoportok stb. A SAM replikációt egyébként a Windows 2000 
tartományvezérlőn futó PDC emulator végzi. A Mixed módnak 
semmi köze ahhoz, hogy a munkaállomások képesek-e a DNS 
segítségével bejelentkezni, telephelyhatárokhoz igazodni stb. 
Ez kizárólag a kliensgépeken múlik. Mixed módban is megtelik a 
DNS zóna az Active Directory dinamikus bejegyzéseivel, melyek- 
kel meg lehet találni a globális katalógust, mellyel meg lehet ta- 
lálni a telephelyek , szélét". 


Native mód 

A Mixed módra addig van szükség, amíg a tartomány vegyesen 
tartalmaz NTA és Active Directory tartományvezérlőket. Amint az 
utolsó BDC-t is megupgradeltük, áttérhetünk Native módra, ami 
az eddigiek értelmében egy rabláncaitól megszabadított Active 
Directory-t ad a kezünkbe. 
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Domain name (pre.windows 2000) 


INETACADEMIA 


Desciiption: 


EST 


Domain operation mode: 
Native mode (no pre:Windows 2000 domain controller). 7. 





A falak leomlanak, a szürke menüpontok kigyúlnak, és szaba- 

don garázdálkodhatunk: 

0 Lehet készíteni Security Universal csoportot 

0? Policyval szabályozható a RAS kapcsolat 

0 A csoportok típusa menet közben megváltoztatható (!). 
Unod a Local csoportot? Alakítsd át Globallá! 

0 A csoportok egymásba ágyazhatók. A tagja lehet B, mely- 
nek tagja ismét A. Ennek a levélküldésben vehetjük egyéb- 
ként hasznát 

B És ne feledkezzünk meg arról sem, hogy innentől több, 
mint negyvenezer objektumunk lehet (de kinek kell?) 

S mi történik a felhasználói kapcsolatokkal? SEMMI. Ha eddig 

volt NetBIOS, ezután is lesz, hisz ennek semmi köze a címtár 

felszabadításához! Bizonyíték kell? 


Kompatibilitási kegyetlenkedések 
Kezdjük a NetBIOS-sal, tiltsuk le! Ehhez a Start Menü-sSet- 
tings-zNetwork and Dial-up Connections-sLocal Area Con- 
nection-sProperties-eInternet Protocol (TCP/IP)-zProper- 
ties-sAdvanced-sWins nevű elhagyatott helyre kell elláto- 
gatnunk, sötétedés után ne járkáljunk arrafelé magányo- 
san, veszélyes környék ;) 
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5 A NetBIOS támogatás letiltása 
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WINDows 2000 MIXED vS. NATIVE 
Ha itt átkapcsolunk Disable NetBIOS-ra, akkor valóban elveszít- 
jük a régi klienseket (beleértve az NT4-eket is) de ennek sem- 
mi köze a Native módhoz, ugyanez a lehetőség ugyanis Mixed 
módban is kiválasztható. Vagy vegyük az NTLM hitelesítést: ha 
megszűnne, ismét csak elveszítenénk egy csomó munkaállo- 
mással a kapcsolatot. Kikapcsolható az NTLM? Persze! De en- 
nek eszköze a csoportos házirend (Group Policy), és nem a Na- 
tive üzemmódra történő átállás! 


PDC Emulator 

S mi lesz a PDC Emulatorral? Megszűnik létezni? Nem! Nem 
szűnhet meg, mert feladata nemcsak a BDC-k felétörténő SAM- 
szerű replikációban volt, hanem fontos kompatibilitási szerepe 
is van: bizonyos kliensek állhatatosan keresik a PDC-t, még ak- 
kor is, ha ennek funkcionálisan semmi értelme sincs, és soha 
nem is volt: a Windows 9x-ek imádják a PDC-t, állandóan szó- 
lítgatják, pedig még a jelszóváltoztatást is beküldhetnék a 
BDC-nek, hisz az továbbítja a kérést a PDC felé. Ha pedig nem 
találnak PDC-t, nagyon bánatosak lesznek, és különböző IPC$ 
nevű megosztásokra futnak rá, ahol persze semmi keresnevaló- 
juk nincs. A PDC Emulator szerep megmarad - hisz semmi kö- 
Ze a SAM rabláncba veréséhez! 


NTCONFIG.POL 
A régi típusú házirendek tökéletesen fognak működni, ha a há- 
zirendfájlt bemásoljuk a NETLOGON megosztásba. 


Fontos átállni Native módra? 

Nem. Nincs olyan címtárfunkció, amely - nekem - hiányoz- 
na a Mixed üzemmódból. A séma Mixed módban is bővíthe- 
tő, az Exchange 2000 feltelepíthető, a több forrású repliká- 
ció működik, a támogatott kliensek használhatják a Kerbe- 
rost... mi kell még? 


Zárszó 

Tudjuk, hogy a Native módra történő átállás veszélytelen (azt 
az egy veszélyt kivéve, hogy nincs visszaút). Ha valakit ezi- 
dáig nem sikerült meggyőznöm a Native mód jelentőségéről, 
most már nem is fog sikerülni. Remélem kiderült, hogy nincs 
szorító kényszer a lépés megtételére. Tüzetesen végigbön- 
gésztem a Resource Kit Deployment Planning Guide-ját, de 
semmi olyasmit nem találtam, ami mágnesként vonzana a 
Native mód felé - ha csak a RAS policyt nem számítom. Kö- 
szönöm, megvagyok egymásba ágyazható csoportok, tízmillió 
objektum és csoportátalkítás nélkül. 


Fóti Marcell, MCSE, MCT, MCDBA, MZ/X 
marcellf(-onetacademia.net 


A MICROSOFT MAGYARORSZÁG SZAKMAI MAGAZINJA 
2001. 04. 


18 


19 


WINDowSs 2000 


Bevezetés 

A rendszergazdáknak sokszor okoz fejtörést az fájlok mennyi- 
ségének intenzív növekedése a kiszolgálókon. Sok helyütt egy- 
re égetőbb ez a probléma, hiszen az Internethozzáférés egyre 
általánosabbá válik, így a dolgozók nagy mennyiségben jut- 
hatnak hozzá képfájlokhoz, egyszerű játékokhoz stb., amelye- 
ket előszeretettel tárolnak a hálózati meghajtókon. Kézenfek- 
vő, de hosszú távon nem a legkifizetődőbb megoldás a kiszol- 
gálók merevlemezegységeinek bővítése. Ennél sokkal nehezeb- 
ben járható út, ha kizárólag adminisztratív úton, számítás- 
technikai szabályzattal próbáljuk meg korlátozni a dolgozók 
gyűjtési szenvedélyét. Ez a módszer ugyan ingyenes, de csak 
akkor működőképes, ha a rendszergazdák a hatóság szerepét 
is felvállalják. Vagyis a számítástechnikusokra hárul a szabály- 
zatba ütköző fájlok eltávolítása a merevlemezekről. A tapasz- 
talatok azonban azt mutatják, hogy a kemény fellépés hatásá- 
ra ,engedetlenségi mozgalom" alakul ki a dolgozók körében: 
minden lehetséges módszert megragadnak arra, hogy a ked- 
venc képeket megtarthassák. Megtörtént eset, hogy az egyik 
dolgozó a Kérlek ne töröld le! elnevezésű mappában tárolta az 
illegálisnak minősülő fájlokat. Nem mindenki hagyatkozik 
azonban a számítástechnikusok jó szívére. Mások inkább átne- 
vezésével próbálják elrejteni féltett fájlukat a kutató pillantá- 
sok elől. Az így kialakuló harc sok időt és energiát vehet el a 
rendszergazdáktól. Ennek a módszernek az alkalmazhatósága 
és hatékonysága tehát erősen megkérdőjelezhető. Legelegán- 
sabb megoldásnak a dolgozók által felhasználható lemezterü- 
let korlátozása tűnik. Így a számítástechnikusoknak nem kell 
a hatóság szerepét betölteniük, és a dolgozók maguk dönthe- 
tik el, hogy a rendelkezésre álló területen a munkához kapcso- 
lódó vagy a szórakozást szolgáló fájlokat tárolják-e. 

A Windows 2000 megjelenéséig a Microsoft operációs rend- 
szerek nem tartalmaztak beépített lemezkvóta szolgáltatást. 
Számos programot fejlesztettek a Windows NT operációs rend- 
szerre, amelyel korlátozni lehet a felhasználható lemezterü- 
let méretét. Ilyen például a W. Ouinn Associates által készí- 
tett OuotaAdvisor (4.1-es verzió) [1], a Northern Parklife féle 
Ouota Server (5.1b verzió) [2] vagy az NTP Software Ouota 
Sentinel (2.1-es verzió) [3] nevű alkalmazása. 


A konkurencia 

Az imént említett termékek közös jellemzője, hogy a Windows 
NT 4.0 mellett már a Windows 2000 operációs rendszeren is 
futnak. Mindháromra igaz az a megállapítás, hogy a szolgál- 
tatások széles körével segítik a rendszergazdák munkáját. Jó 
példa erre, hogy a korlátozásokat nemcsak kötet-, de mappa- 
vagy akár fájlszinten is meg tudjuk adni. Ezen túlmenően fel- 
használókra, illetve felhasználói csoportokra is vonatkoztat- 
hatjuk a kvótabeállítást. Ez utóbbi különösen olyan esetben 
hasznos, amikor például egy munkacsoportnak adunk hozzá- 
férési jogosultságot egy hálózati meghajtóhoz. Az imént em- 
lített szolgáltatás révén a csoport minden tagjának egysége- 
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Lemezkvóta 


a gyakorlatban 


sen megszabhatjuk, hogy mekkora lemezterületet használhat 
fel az adott meghajtón. Ha új tag kerül a csoportba, akkor a 
kvóta természetesen rá is automatikusan vonatkozik. 

A felsorolt három termék rendelkezik olyan beállítási lehető- 
séggel, amelynek eredményeképpen az újonnan létrejött ob- 
jektumok automatikusan öröklik a megfelelő kvótaértéket. Ezt 
a szolgáltatást a OuotaAdvisor esetében Learn Mode kvótának 
hívják, amely nagyon jól használható például a felhasználók 
kezdőmappájának (home directory) korlátozására. Ha arra a 
könyvtárra engedélyezzük ezt a beállítási formát, amely a kez- 
dőmappákat tartalmazza (például IIKiszolgálónév1E$ IUserHo- 
mes), akkor minden újonnan létrehozott első szintű almap- 
pán (például )IKiszolgálónévlD$UserHomes IBurgundiM) ér- 
vényre jut az általunk meghatározott korlátozás. Felhaszná- 
lókra is alkalmazhatjuk a kvótázás ezen típusát, amely nagyon 
hasznos a publikus mappák méretének szabályozásakor. 


Set guota (ait XI 


fduota Objects: 


D:AUserHomes 


Object Guota (Absolute) . Lear Mode ] User Guotas ] 








Use the directory lear mode option to sense when dírectoties are 
created within an object. Use the user leam mode options to 
automatically sense when users occupy space on an object, 


Directory Leam Options 
[7 AutoDetect SubDirectories 


Apply Template:. [NAZRÁ150 MB Ouota u 


User Lean Options 
TT AutoDetect Users 





TT Exciude Administrators 


TT Check For Group Associations 


o As ől SESSESEZE ENE DI 











CE] ere 





5 OuotaAdvisor 


A három kvótázóprogram közül a OuotaSentinel 2.1-ben talál- 
ható a beállítások öröklődésének legösszetettebb formája. Az 
úgynevezett EASE technológia (Enterprise Application Services 
Extension) révén egységes felület áll rendelkezésünkre az 
összes Ouota Sentinel kiszolgáló és az EASE technológiára fel- 
készített alkalmazások kezelésére. 
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Ez zIDi2d 
E iz Type — Tsz Desart 
7-I] Budapest Öludapest 
a 2 AzRA eger Centainer 
EB EASE srstem Manager [djmskoke esazzad 
AE reset retoistes  föszees Contaner 
E ÉJ Server Drectates 
29 (c 
Éz 2 user Temelates 
5. Eger 
5 CI] Miskol 
a 3 szeged 
jabeszoszezmeezrtes] 2] 
4 objects) TERT 
5 OuotaSentinel 
A kiszolgálók hierarchiába rendezésével leképezhetjük válla- 


latunk szervezeti felépítését. Az öröklődési szabályok értel- 
mében a beállítások a hierarchia magasabb szintjétől az ala- 
csonyabb felé terjednek tova. Például ha az értesítési üzene- 
tek küldését minden esetben ugyanarra a kiszolgálóra szeret- 
nénk bízni, akkor ezt a hierarchia csúcsán, a szervezet szint- 
jén érdemes beállítani. A változtatások az adatok replikáció- 
ja révén minden Ouota Sentinel kiszolgálóhoz eljutnak. 
Általánosan elterjedt szolgáltatásnak számít az értesítési 
üzenetek küldése is. A jellemzett alkalmazásoknál nekünk 
kell meghatároznunk, százalékos formában, azt a küszöbér- 
téket, amelynek elérésekor a program figyelmeztető üzene- 
tet küld. Például 50 MB-os kvóta és 809o-os küszöbérték 
esetén a program akkor küld értesítési üzenetet, amikor a 
felhasznált lemezterület mérete elérte vagy meghaladta a 40 
MB-ot. Minden kvótabeállítás során lehetőségünk van több 
különböző küszöbérték meghatározására, melynek száma 
például a OuotaSentinel esetében nem kevesebb, mint 200! 
Az üzenetek létrehozásakor módunkban áll változókat (kü- 
szöbérték, kvóta mértéke stb.) is illeszteni a szövegbe, amely 
nagyban növeli a tájékoztatás információtartalmát. 


Threshold Properties E 2 


Threshold Commands ] 
OwnerMessages — ] 


Triggering User Messages ] 
General Other Recipient Messages 


"Below Threshold Message 
Email Subject: 


EE 


Email and Popup Text. 

















Above or Write Denied Threshold Message 
Email Subject: 


Ouota Sentinel - értesítési üzenet 


Email and Popup Text: 
Kedves Rendszergazdal 












21 nevű felhasználó túllépte a határérték (ZL MB) ZT százalékát! 











Cancel Help 


5 A OuotaSentinel riasztási beállításai 
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A figyelmeztető üzenet megjelenhet párbeszédablak formá- 
jában, amikor a felhasználó átlépte a határértéket, de érkez- 
het elektronikus levélként is, például a rendszergazda címé- 
re. A OuotaAdvisor, a Ouota Server és a OuotaSentinel is tá- 
mogatja az SMTP protokollt. 

Mivel az alkalmazások sokféle beállítási módot tesznek lehe- 
tővé, a lemezterület kihasználtságnak nyomon követése nem 
könnyű feladat. Gondoltak erre a programfejlesztők is, így a 
kimutatások készítésére beépített eszközök állnak a rendel- 
kezésünkre. Bár ezen eszközök által nyújtott szolgáltatások 
között nagy különbség mutatkozik az egyes kvótázó progra- 
mok vonatkozásában, az aktuális állapot áttekintésében je- 
lentős segítséget nyújtanak. Az elkészített kimutatásokat 
többféle fájlformátumban is elmenthetjük (például text vagy 
HTML), sőt a OuotaServer ODBC kompatibilis adatbáziskeze- 
lőkkel is képes együttműködni. 

A kvótázóprogramok által nyújtott szolgáltatások teljes tárhá- 
zának áttekintése túlmutat ennek a cikknek a keretein. Ezért 
e rövid ízelítőt követően nézzük meg, hogy a Windows 2000 
operációs rendszer mit kínál számunkra ezen a területen. 


Lemezkvóta a Windows 2000 operációs rendszerben 

A lemezkvótaszolgáltatás csak a Windows 2000 új fájlrend- 
szere alatt használható. Nem alkalmazhatjuk tehát a lemez- 
terület korlátozásának ezt a fajtáját például FAT-es meghaj- 
tókon. (Az NT 4.0 NTFS fájlrendszerét a Windows 2000 auto- 
matikusan frissíti.) A kvótázás csak kötetek (partíciók) szint- 
jén engedélyezhető. Ezt azért fontos hangsúlyozni, mert egy 
lemezegységen több kötet is létrehozható, illetve egynél több 
fizikai lemez is állhat a kötet hátterében. Ebből az is követke- 
zik, hogy sem a mappák, sem a fájlok szintjén nem tudjuk a 
korlátozást érvényesíteni. Ugyancsak fontos jellegzetesség, 
hogy a lemezterület felhasználásának ellenőrzése azon alap- 
szik, hogy ki a fájlok tulajdonosa. Csoportokra tehát nem 
szabhatunk ki lemezkvótát, hisz minden fájl egyetlen tulajdo- 
nossal bír - alapértelmezésben az a tulajdonos, aki létrehoz- 
ta. Ez alól csak az Administrators csoport képezhetne kivételt, 
hiszen a tagjai által létrehozott fájlok tulajdonosa mindig a 
csoport lesz. Természetesen a rendszergazdák számára nincs 
értelme kvótát beállítani, sőt esetükben az operációs rendszer 
nem is teszi lehetővé a lemezhasználat korlátozását. 

A lemezkvótát a kötet Properties párbeszéd ablakán tudjuk 
engedélyezni. Ehhez a Ouota fülön található Enable guota 
management jelölőnégyzetet kell kiválasztanunk. 


d$ on azra" (0-) Properties 7 2 





General] Secuzty  Ousta 


$ Statu Dízk auota system iz active. 


FF. Enabie auota management 
I. Dery ők space to users exceedng auota ím 
Select the dealt avota nni for new usert on this vokame 
C Dgnotfmi csk úrage 
(7 Limit sk spaceto [ 50 [me r] 


Set waming level to 5 [me 7 











Select the guota logging optons for this volume: 


F7 [og event when a user excsedr bei guota Ér 
IT Logeyent when a uset exceedz iheit waming level 





5 A Windows 2000 kvótarendszere 
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Első lépésként az operációs rendszer feltérképezi, hogy melyik 
felhasználó mekkora területet foglal le a szóban forgó köte- 
ten. Alapértelmezésben az operációs rendszer kvótatúllépés 
esetén nem tiltja le a lemezterületet. A letiltáshoz a Deny disk 
space to users exceeding guota limit jelölőnégyzetet kell ki- 
választanunk. Kétféle határértéket tudunk beállítani. Egyrészt 
megszabhatjuk, hogy a köteten mekkora hellyel gazdálkod- 
hatnak a felhasználók (Limit disk space to mező) , másrészt le- 
hetőségünk van figyelmeztetési értéket is megadni (Set war- 
ning level to mező). Fontos felhívni a figyelmet arra, hogy az 
itt megadott értékeknek akkor van szerepük, amikor az ope- 
rációs rendszer a kvótát hozzárendeli a felhasználókhoz. 
Vagyis a kvótázás legelső engedélyezésekor, illetve akkor, 
amikor egy új felhasználó hoz létre (vagy vesz tulajdonába) 
egy fájlt a szóban forgó köteten. A Limit disk space to, vala- 
mint a Set warning level to mezők tartalma tehát nincs ha- 
tással a már érvényben lévő kvótabeállításokra. 

A határértékek túllépéséről bejegyzés készül az eseménynap- 
lóba, amennyiben a Log event when a user exceeds their gu- 
ota limit, valamint Log event when a user exceeds their war- 
ning level beállítást engedélyezzük. 

Az események naplózására alapértelemzésben óránként kerül 
sor. Ezt az időintervallumot a regisztrációs adatbázisban tud- 
juk módosítani. A 


HKEY LOCAL MACHINENlSystemlCurrentControlSetYt 
b ControlWileSystem 


kulcs alatt hozzuk létre az NtfsOuotaNotifyRate (DWORD) ne- 
vű bejegyzést, amelynek értékét másodpercekben számolva 
kell meghatároznunk. Sajnos a figyelmeztetési érték túllépé- 
séről az érintett felhasználót az operációs rendszer semmilyen 
formában sem értesíti. 

A kvótabejegyzéseket a Ouota fülön található Ouota Entries 
gomb megnyomásával tudjuk megtekinteni. 
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Nagyon izgalmas lehetőség a fenti ablak drag-and-drop 
képessége: egyszerűen húzzuk át Excelbe a bejegyzéseket! 


Az egyes dolgozókhoz tartozó határértékeket is ezen a felüle- 
ten lehet megváltoztatni. Egy időben nemcsak egy bejegyzés 
tulajdonságát tudjuk megjeleníteni, így a több felhasználót 
érintő változtatás egyszerre is megvalósítható. 

A Ouota menü New Ouota Entry parancsával olyan felhaszná- 
lók számára is létrehozhatunk bejegyzéseket, akiknek nincs 
birtokukban fájl a szóban forgó köteten. Ez a lehetőség akkor 
lehet hasznos, ha nem vezetünk be általános érvényű korlá- 
tozást (a Ouota fülön a Do not limit disk usage rádiógombot 
jelöljük ki), csak néhány dolgozó számára akarjuk megszabni 
a felhasználható lemezterület méretét. 

A felhasználói azonosító törlésével a kvótabejegyzés nem tör- 
lődik automatikusan. Mivel az operációs rendszer már nem 
tudja a bejegyzést egy létező felhasználói objektumhoz társí- 
tani, ezért a Ouota Entries ablak Name oszlopában az [Acco- 
unt Information Unavailable] felirat, míg a Logon Name osz- 
lopban a felhasználó SID-je jelenik meg. A kvótabejegyzés el- 
távolítását azonban mindaddig nem végezhetjük el, amíg a 
köteten található olyan fájl, amelynek a törölt felhasználó a 
tulajdonosa. Erről az alábbi párbeszédablak tájékoztat: 

als 


—— Files are consuming disk space for 1 of the selected guota entries. These entries 
cannot be deleted until the disk space is freed up. 








Ustiez owned by. TETT BENENENNEESSENETES EEEN -] 





File Name In Folder 
GRAPH.EXE DAUserHomestRtendeB 
EXCELEXE DA serHomestRtende8 


MSO9OLL D:AXUserHomestRtendeB 


OUTLUBOLL D:AserHomesXRendeB 


MSACCESS.EXE D:XUserHomestRtendeB 
POWERPNT.EXE DA serHomestRtendeB 
MSOWCOLL DAUserHomestRendeB 
WINWORD.EXE D:AXserHomestRtende8 


Select an option for the selected files 


Permanently delete files. Delete 
Take ownership of files. Take Ownership 


Move files to: Browse... Move 
































BUNLTINYAdmánéstrators — 24646MB Nom No Lent NA 
[A warning Kampós Rozáka . KamposRápttypo.hu 45.91 MB 508 3548 91 
or Melton Viimos Meltonyápttypo-hu 4.15M8 5048 35we 
[Awanng RendeBéla ——— RendetGtypo.hu 38.04 MB Some 3swe n 











ÍS total kem45), 1 selected. 





5 Windows 2000 kvótabejegyzések 


Mint a képen is látható, az Administrators csoport tagjai szá- 
mára alapértelmezésben nincs beállított határérték. Ahogy 
korábban már volt róla szó, kvótát nem is tudunk a csoport 
számára meghatározni, csak a figyelmeztetési értéket tudjuk 
megváltoztatni. A párbeszédablakról a kvótabeállítással kap- 
csolatos minden fontosabb információ leolvasható. Az áttekint- 
hetőséget növeli, hogy az adatok az egyes oszlopok szerint sor- 
ba rendezhetőek. Több száz felhasználó esetén ennek ellenére 
sem könnyű megtalálni a keresett bejegyzést. Ilyen esetben az 
Edit menü Find parancsa lehet segítségünkre, amellyel a teljes 
bejelentkezési név alapján tudunk keresni. Sajnos az első né- 
hány karakter begépelése nem elegendő, ekkor érdemes lehet 
más elemzőeszközt (például Excel-t) igénybe venni. 
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Close 


5 Mi történjen a törölt felhasználó fájljaival? 





Több választási lehetőségünk is adódik. Egyrészt saját tulaj- 
donba vehetjük a szóban forgó fájlokat (Take Ownership nyo- 
mógomb). Másrészt átmozgathatjuk őket egy másik kötetre 
(Move files to mező). Harmadrészt véglegesen letörölhetjük 
ezeket a fájlokat (Delete nyomógomb). 

A rendszergazdai feladatok egyszerűsítése végett lehetősé- 
günk van a felhasználókhoz tartozó kvótabeállításokat átvinni 
egyik kötetről a másikra. Ezt legegyszerűbben úgy tehetjük 
meg, hogy megjelenítjük mindkét kötet Ouota Entries ablakát, 
majd a forráskötet ablakából egyszerűen áthúzzuk a kijelölt 
kvótarekordokat a másik Ouota Entries ablakba. Arra is lehető- 
ségünk van, hogy a kijelölt felhasználók beállításait Ouota me- 
nü Export parancsával egy tetszőleges kiterjesztésű fájlba el- 
mentsük. Szükség esetén ezeket az adatokat bármelyik köte- 
ten érvényre juttathatjuk a Ouota menü Import utasításával. A 
kvótabeállításokat Windows 2000 Professional operációs rend- 
szeren futó munkaállomásról is kezelhetjük. Ehhez a megosz- 
tott kötetet egy meghajtójelhez kell hozzárendelnünk. 
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Lemezkvóta a felhasználók oldaláról 

A felhasználók számára az egyik legfontosabb kérdés, hogy 
mennyi szabad hellyel rendelkeznek a hálózati meghajtókon. A 
munkavégzés szempontjából nagyon lényeges, hogy mennyire 
könnyű ezzel kapcsolatban pontos információhoz jutni. A sza- 
bad lemezterület nagyságát a legegyszerűbben a My Computer 
ablakban tekinthetjük meg. Ha engedélyezve van a lemezkvóta, 
akkor a hálózati meghajtó teljes kapacitásaként a felhasználó- 
hoz rendelt kvótaérték jelenik meg. Természetesen az is egyér- 
telműen megállapítható, hogy mennyi a felhasználható szabad 
terület. A bonyodalom akkor kezdődik, ha ugyanazon a kvótá- 
zott köteten több különböző megosztáshoz is csatlakozott a fel- 
használó. Ekkor válik ugyanis nyilvánvalóvá, hogy az operációs 
rendszer a köteten lévő szabad terület méretét mutatja meg. 














ee BE zo 2xi 
] Ele Edt Wiew  Favorites Iools Help ] 

I] €őzrk - 9 - Gal] search zFolders EgHistory [ Zú BE X ni 

(adoress [Ed My computer s] És ] 
Name / Type Total Size Free Space 
[e93.s Floppy (A:) 3.5-Inch Floppy Disk. 

EgLocal Disk (C) Local Disk 195 GB 1,61 GB 
EgLocal Disk (D:) Local Disk 6,06 GB 492 GB 
EJRemovable Disk (E:) Removable Disk 

ég compact Disc (F:) Compact Disc 

£9 compact Disc (G:) Compact Disc 





Network Drive 
Network Drive 
ZD documents on "azra! (W:) Network Drive 
EE burgundim on "azrat (X:) Network Drive 
EE marketing on "azra! (Y:) ——— Network Drive 
(eg control Panel System Folder 


programs on "azra! (P:) 
public on "azra! (A:) 











[12 object(9) [ I Wy computer 4 
5 A hálózati megosztások ugyanazon a kvótázott köteten 
találhatóak. A My Computerben megjelenő adatok azt su- 
gallják, hogy mindegyik hálózati meghajtón majdnem 40 
MB üres hely van, holott összesen ennyi a felhasználható 
szabad lemezterület 


Ez félrevezető, főleg, ha figyelembe vesszük: a felhasználó 
nem látja, hogy az adott hálózati megosztás a kiszolgáló le- 
mezegységének melyik kötetén található. A fájlkezeléssel 
kapcsolatban is megfigyelhető némi bizonytalanság. Ha 
ugyanazon a kvótázott köteten lévő két megosztáshoz kap- 
csolódunk, és megpróbálunk a rendelkezésünkre álló szabad 
helynél nagyobb méretű fájlt átmozgatni az egyik hálózati 
meghajtóról a másikra, akkor , Nincs elég szabad lemezterü- 
let" hibaüzenetet kapunk. Ez egyrészt azért meglepő, mert a 
mozgatáskor nem nő a lefoglalt lemezterület mérete. 
(Network Monitorral persze látszana az igazság, ennek 
fényében a jelenség már egészen érthető lenne -— szerk.) Más- 
részt azért is különös, mert ha ugyanazon a hálózati meghaj- 
tón az egyik mappából a másikba mozgatjuk át az fájlt, ak- 
kor az operációs rendszer gond nélkül elvégzi a feladatot. 

A felhasználók számára az elosztott fájlrendszeren (Distribu- 
ted File System - DFS) keresztül is biztosíthatunk hozzáférést 
a hálózati erőforrásokhoz. A DFS segítségével a hálózaton fi- 
zikailag elosztott megosztásokat úgy jeleníthetjük meg, mint- 
ha a hálózat ugyanazon helyén lennének. Ez a gyakorlatban 
azt jelenti, hogy a felhasználó csak egy hálózati meghajtót lát 
(DFS-gyökér) , és a különböző kiszolgálókon lévő megosztások 
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úgy látszanak, mintha a hálózati meghajtón lévő mappák len- 
nének. Abban az esetben, ha a DFS-gyökér kvótázott köteten 
található, akkor a felhasználó a hálózati meghajtó kapacitá- 
saként a neki beállított kvótaértéket fogja látni. Ez abban az 
esetben fedi a valóságot, ha a DFS-gyökér és a hozzá kapcsolt 
megosztások ugyanazon a köteten találhatóak. Ellenben, ha a 
hálózati megosztások különböző kvótázott köteten helyez- 
kednek el, akkor a felhasználó számára gyakorlatilag követhe- 
tetlenné válik, hogy hol mennyi szabad hely áll a rendelkezé- 
sére. Hiába jeleníti meg ugyanis a DFS-gyökér alatti mappák 
tulajdonságait, semmi erre vonatkozó adatot nem fog találni. 
Szintén lényeges kérdés, hogy az alkalmazások milyen hiba- 
üzenetet küldenek, amikor a felhasználó már kihasználta a 
rendelkezésére álló szabad területet. A bonyolult, nehezen 
érthető, hexadecimális hibakódokkal tűzdelt üzenet ugyanis 
komoly aggodalmat válthat ki a dolgozókból, amelyet csak a 
rendszergazda megnyugtató szavai csillapíthatnak. Ebből a 
szempontból a Windows 2000 Professional és a Windows NT 
4.0 Workstation , beépített" alkalmazásai (Wordpad, Windows 
Explorer stb. ) eredményesen vizsgáztak. Az üzenetek rövidek, 
jól értelmezhetőek voltak, és a tájékoztató valamilyen formá- 
ban szerepelt a disk full vagy a not enough space on the disk 
kifejezés. Egyedül a Windows 2000 Notepad-je küldött némi- 
leg megtévesztő hibaüzenetet. Abban az esetben, ha a köte- 
ten már létezett a text fájl, amit szerkesztünk, de elmenté- 
sekor már túllépnénk a határértéket, a Notepad a következő 
tájékoztatást adja: Cannot open the file. Make sure a disk in 
the drive you specified. Érdekes, hogy ezzel szemben a Win- 
dows NT 4.0-ban található Notepad ebben a speciális eset- 
ben is korrekt tájékoztatást küld. 

Hasonlóan jók a tapasztalatok az Office 97 és az Office 2000 
alkalmazásai esetében. Az operációs rendszer még a makróval 
elvégzett fájlműveleteknél is egyértelmű visszajelzést adott. 

A Windows 2000 Professional-ban újításként jelent meg az 
Offline mappák használatának lehetősége. A szolgáltatás lé- 
nyege a következő: bármelyik hálózati mappánál megadhat- 
juk, hogy a könyvtárban szereplő fájlok akkor is elérhetőek 
legyenek a munkaállomáson, amikor nincs hálózati kapcso- 
lat. Amint helyreáll az összeköttetés a kiszolgálóval, az ope- 
rációs rendszer szinkronizálja a kiszolgálón lévő példányt a 
helyi másolattal. Előfordulhat azonban olyan eset, hogy a lo- 
kális fájl mérete annyival megnövekedett, hogy a szinkroni- 
zálás során túllépnénk a kvótát. Ilyenkor az operációs rend- 
szer nem tudja frissíteni a hálózati meghajtón lévő példányt. 
A tájékoztató üzenetben egyértelműen szerepel a kudarc oka: 
a kiszolgáló lemezegysége megtelt. 








55 Synchronization Complete zIDI21 
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5 A kvóta igazságos: az Offline dolgozókra is érvényes 
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Az operációs rendszer továbbra is érzékeli, hogy a helyi és a 
hálózati adatok eltérnek egymástól, így a szinkronizálást 
megpróbálja elvégezni minden be- és kijelentkezéskor 
(amennyiben a beállításnál engedélyeztük ezt a szolgáltatást) . 

Speciális. esetnek számít az eltérő adatfolyam (data stream) 

használata fájlok esetében. Az NTFS fájlrendszeren lehetősé- 

günk van ilyen módon adatokat kapcsolni az fájlokhoz. Az 
adatfolyam a következő jellegzetességekkel rendelkezik: 

5 Nem jelenik meg sem az Explorer felületén, sem a 
parancssori DIR utasítás hatására. 

-2 Tartalmának megjelenítéséhez ismerni kell a pontos nevét. 
0 Az operációs rendszerben nincs beépített eszköz arra, 
hogy a lemezegységen lévő adatfolyamokat kilistázzuk 
vagy letöröljük. Az előbbi feladatra nagyon jól használha- 
tó a Frank Heyne LDAS (List Alternate Data Stream) [4] 
nevű ingyenesen letölthető programja. 
Létrehozásához nem szükséges kiemelt jogosultság, így a 
felhasználóknak lehetőségük van arra, hogy adatokat rejt- 
senek el a rendszergazdák elől. 
Létrehozása többféleképpen is történhet. Például ha a 
teszt.txt nevű fájlhoz szeretnénk adatfolyamot kapcsolni, 
akkor parancssorból adjuk ki a következő utasítást: note- 
pad.exe teszt.txt: adatfolyam.txt. Ennek hatására egy új, 
rejtett fájl jön létre, amely az elmentést követően szoros 
kapcsolatban lesz a text.txt-vel. 

A fájl másolása, mozgatása érinti a hozzá tartozó 

adatfolyamot is. 

"0 Az adatfolyam eltávolítása csak közvetett módszerekkel 
oldható meg. Például ha a text.txt-t átmozgatjuk FAT-es 
partícióra, akkor az adatfolyam automatikusan törlődik, 
mivel ez a fájlrendszer nem támogatja az adatfolyam lét- 
rehozását. Ezen kívül a text.txt tartalmát átmásolhatjuk 
egy másik fájlba. Ezután a text.txt letörlésével megsem- 
misítjük az adatfolyamot is. 

Mivel az adatfolyamok kezelésére nincsenek beépített esz- 
közök, ezért felmerülhet a kérdés, hogy a Windows 2000 le- 
mezkvóta szolgáltatása megkerülhető-e ezzel a módszerrel? 
A válasz egyértelműen, és hacker szempontból sajnálato- 
san: nem. A kvótát meghaladó mértékű adatfolyamot nem 
lehet elmenteni a lemezegységre. Más a helyzet azonban a 
cikkben szereplő kvótátzó programok esetében. A tapaszta- 
latok azt mutatják, hogy a OuotaAdvisor 4.1, a Ouota Ser- 
ver 5.1b és a Ouota Sentinel 2.1 alkalmazások közül egye- 
dül a Ouota Server 5.1b-t készítették fel az adatfolyamok 
kezelésére. A OuotaAdvisor 4.1 és a Ouota Sentinel 2.1 ese- 
tében tehát kijátszható a korlátozás. 


b 
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Összegzés 

A Windows 2000 operációs rendszer beépített lemezkvótája a 
szolgáltatások területén ugyan elmarad a piacon kapható ko- 
molyabb kvótázó programoktól, de megbízható, jól használ- 
ható eszköz. Nagy hátránya viszont, hogy nincs lehetőség ar- 
ra, hogy a felhasználók üzenetet kapjanak: mikor közelítenek 
a rendelkezésükre álló lemezterület felső határához. Ennek 
hiányában csak arról értesülnek, hogy nincs már több szabad 
hely például a dokumentum elmentésére. 

Szintén problémák forrása lehet a lemezkvóta azon jellegze- 
tessége, hogy csak felhasználók szintjén lehet a korlátozást 
érvényre juttatni. Ez főként a közepes és nagyvállalatoknál 
gyakori publikus meghajtók esetében jelenthet gondot. Jelle- 
génél fogva az ilyen hálózati meghajtókon a dolgozók egymás 
dokumentumait is szerkeszteni tudják. A fájl mentésekor 
azonban nem változik meg a fájl tulajdonosa. Ez alapjául szol- 
gáltathat a rosszindulatú tréfáknak: például igen nagy mére- 
tű kép illesztése a kevéssé kedvelt munkatárs tulajdonában 
lévő dokumentumba... Mivel sem a kötetekre, sem a könyvtá- 
rakra nem szabhatunk ki kvótát, a dolgozók növekvő száma 
esetén nehéz biztosítani, hogy a lemezegység ne teljen meg. 
A tapasztalatok szerint érdemes arra is figyelni, hogy a fel- 
használónak ne legyen két különböző hálózati meghajtója 
ugyanazon kvótázott kötetről. Ez azért lehet fontos, mert el- 
lenkező esetben nehezebb megállapítani a szabad lemezterü- 
let méretét. Ezen kívül a hálózati meghajtók közötti fájlmoz- 
gatás is komplikációkat okozhat. 

Mindent egybevéve nagy előrelépést jelent, hogy a lemez- 
terület korlátozását már az operációs rendszer szintjén is 
meg tudjuk oldani. A Windows 2000 ezen szolgáltatása szá- 
mos esetben kielégítheti az igényeket. Valószínűleg azon- 
ban a konkurens kvótázóprogramok a közeli jövőben nem 
fognak eltűnni a piacról. 


Tomasz Balázs 
balazs.tomasz(ohu.hypovereinsbank.com 
pszichológus 


[1] http://www.wguinn.com 

[2] http://www.northernparklife.com 
[3] http://www.ntpsoftware.com 

[4] http://www.heysoft.de 
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Hasznos apróságok 

Cikksorozatunkban a Windows 2000-hez kapcsolódó hasznos 
Microsoft segédprogramokat részletezem. Többségük parancs- 
soros, bár jónéhány grafikus felülettel rendelkezik, és általá- 
ban batch állományokból, scriptekből jól vezérelhetők. A ve- 
gyesfelvágott jelleget erősítendő az alábbi forrásokból emelek 
ki alkaimanként néhány fontosabb eszközt: 

0 1. Windows 2000 Server 

2 2. Windows 2000 Support Tools 

0 3. Windows 2000 Server Resource Kit 

Először is tisztáznám a különböző források elérhetőségét. Az 
első csoportba a Windows 2000 Server telepítésekor a rend- 
szerben alapértelmezés szerint megtalálható programok kerül- 
tek. Ezen sorozatban kizárólag azokat a parancsokat szedem 
elő, amelyek messze értékükön és lehetőségeiken alul haszná- 
lunk, vagy általánosan nem ismertek. A Windows 2000 Sup- 
port Tools tartalmához a már említett Windows 2000 telepítő 
CD-n a X:YSUPPORTWOOLSY könyvtár tartalmának telepítésé- 
vel juthatunk hozzá. Itt a setup.exe lefuttatásával települ a 
support.cab állomány, teljességében kb. 20Mb tárigénnyel. 
Sokan nem ismerik ezen ingyenes eszközkészlet hasznosságát, 
remélem sikerül majd bebizonyítanom létjogosultságát és 
fontosságát. A harmadik csoportba a (sajnos) fizetős Resour- 
ce Kit CD mellékletén található segédprogramok tartoznak. 
Fontos megjegyezni, hogy ezen MS Press kiadvány (és a Supp- 
lement One kiegészítésének) beszerzése mellett más lehetősé- 
geink is vannak. Lehet, hogy már rendelkezik ezen erőforrá- 
sokkal, csak még nem tud róla! A Microsoft Technet (nem az 
újság, hanem a CD!!) előfizetéssel járó CD-gyűjtemény tartal- 
mazza a Resource Kit CD-k anyagát, valamint az MSDN előfi- 
zetők (ezáltal a Certified Partnerek is természetesen) az MSDN 
letöltési szekcióból [1] érhetik el. Ezen kívül a nyilvános [2]- 
es címről ingyenes minták is letölthetőek. Természetesen az 
utóbbi opciók nem tartalmazzák a Resource Kit nyomtatott, 
méretes polcfoglaló anyagát, csak Windows Help formában ki- 
vonatokat. Ne feledjük, hogy a segédprogramok csak egy ré- 
szét képezik ennek az értékes kiadványnak, és nem csak a 
Microsoft által készített kiegészítéseket tartalmazza. 


oft 
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A 80-100 MB tárhelyet foglaló anyag bőven ad lehetőséget a 
csemegézésre. A telepítés után azonban a CD-re még szükség 
lehet, az alkalmazások egy része manuálisan, később telepí- 
tendő onnan. A Supplement One feltételezi az alap Resource 
Kit meglétét, azonban főleg kiegészíti azt új, előre elkészített 
scriptek tömkelegével. 


Kategóriák 

A Support Tools és a Resource Kit segédprogramjait kategó- 
riákba rendezve találjuk meg .cab formában a CD-n, és telepí- 
tésük után is így értelmezhetjük őket legegyszerűbben. A 
Computer Management Tools között találhatjuk a processzek- 
kel, szolgáltatásokkal, a regisztrációs adatbázissal, az ese- 
ménynaplóval, és a felhasználói profilokkal foglalkozó progra- 
mokat. A Deployment Tools szekció a tömeges, automatizált, 
kibővített telepítés eszközeiről szól. Itt összefuthatunk a 
rendszerházirendek, nyomtatók és címtárak migrációjához, 
átmozgatásához nélkülözhetetlen eszközkészlettel és doku- 
mentációval. A Desktop Tools kategória kizárólag a Resource 
Kit-ben van jelen. Többnyire grafikus kezelőfelületűek, és a 
képernyő, a billentyűzet valamint a Windows Explorer kényel- 
mét növelik. A Diagnostic Tools elnevezés magáért beszél, Is- 
ten adja hogy ne legyen rájuk szükségünk! Hálózati (RPC, 
PPTP, SNMP) és helyi eszközök itt vegyesen vannak jelen, a 
hardverközeli és magasszintű, Active Directoryt és tartomány- 
vezérlőket diagnosztizálóak egyaránt ide tartoznak. A File and 
Disk Tools az alacsonyszintű merevlemez-szerkesztéstől és ál- 
lomány-összehasonlítótól, a vágólap és az állomány-kiterjesz- 
tések kezelésétől a DFS és Remote Storage ellenőrzéséig ter- 
jed. A Resource Kit IIS kategóriája a  webkiszolgálók diagnosz- 
tikai és rendszerkezelési segédletét erősíti. A Network Mana- 
gement Tools lakosai az ADSI, DHCP, DNS, LDAP, AD; termi- 
nál-szolgáltatásért folytatott küzdelmekben jöhet jól. A Per- 
formance Tools alatt a teljesítmény-finomhangoláshoz elen- 
gedhetetlen gyöngyszemek rejtőzködnek. A scriptelésről szó- 
ló külön cikkek miatt nem részletezném most a Scripting Tools 
tartalmát, de... 


Segítség 

A dokumentáció erőforrástól függően változik, a Support 
Tools és a Resource Kit részletes, szabályos Windows Help for- 
mátumú anyaggal támogatja a tartalmát, amiket a Tools Help 
hivatkozással tudunk elérni. Az alap Windows 2000 parancso- 
kat a gépen és a weben található súgóból érthetjük meg. Ahol 
ez nem egyértelmű, megadom a szükséges webcímet. Az első 
alkalommal a , szerelem első látásra" kategória győzteseit vá- 
lasztottam ki, különböző területekbe belekóstolva. 


Az IIS újraindítása: iisreset.exe 

Windows 2000 Server része 

x:winntisystem32 Visreset.exe 

Az fisreset segítségével az IIS szolgáltatásokat immáron meg- 
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bízhatóan tudjuk újraindítani karbantartási célzattal, az alap 
operációs rendszertől függetlenül. Az iisreset parancssoros 
funkcionalitása nagyjából megegyezik az MMC-modul Internet 
Services Managerből elérhető ,Restart IIS..." paranccsal. 
Azonban a paraméterezhetőségét figyelembe véve sokkal fi- 
nomabban vezérelhető, és természetesen időzíthető is. Ez ki- 
fejezetten hasznos lehet a bizalmatlan (memória-telítődéstől 
tartó) rendszerfelelős számára. Mellesleg az IIS dokumentáció 
[3] külön felhívja a figyelmünket arra, hogy ne az , alap" Ser- 
vices felülettel vezéreljük az IIS-t. Fontosabb paraméterezése 
a következő lehetőségeket adja: 


iisreset [gép neve] [paraméterek] 


Ha nem adjuk meg a gép nevét, akkor alapértelmezés szerint 
a helyi szolgáltatásokra vonatkoztatja az utasítást. Paraméte- 
rek nélkül egy teljes körű szolgáltatás-újraindítást végez el. A 
szolgáltatásokat a /START és /STOP paraméterekkel indíthat- 
juk és állíthatjuk meg. A /RESTART az előző két paramétert 
kombinálja. A gépet a /REBOOT esetében indítja újra. A . /RE- 
BOOTONERROR lehetővé teszi hogy kizárólag a szolgáltatások 
újraindítása során bekövetkező kritikus hiba esetén induljon 
újra a gép. A /NOFORCE kapcsoló erőszak-mentes viselkedésre 
készteti az iisreset-et, így nem próbálja végtelen időkig elvé- 
gezni a feladatát. Az IIS újraindítását a /DISABLE és /ENABLE 
kapcsolókkal letilthatjuk és engedélyezhetjük. Egy ötlet a fel- 
használására: a kiszolgáló Services menedzsmentfelületén az 
IIS Admin Service esetében a Recovery fülön megadhatjuk 
(mint minden más szolgáltatás esetében is), hogy az adott 
szolgáltatás elhalálozása esetében lefuttasson egy parancsot. 
Ez a parancs lehet például az iisreset.exe (hiszen emlékszünk, 
hogy külön az IIS Admin Service újraindítása nem szerencsés). 


Remote Shutdown: távoli rendszerleállítás 

Windows 2000 Resource Kit 

Network Management Tools 

Shutdown.exe 

Ez a kombinált parancssoros és grafikus felületű segédprog- 
ram szegény felhasználók rémálma, és egyben a rendszerüze- 
meltetők mennyei segédlete. Adminisztrátori jogokkal rendel- 
kezve segítségével pillanatok alatt újraindíthatjuk vagy lekap- 
csolhatjuk bármelyik munkaállomást a LAN-on. Ha paraméte- 
rek nélkül indítjuk, akkor a GUI jelenik meg, egyébként 
csöndben konzolon is elfutkározik. A /? kapcsolóval kivallat- 
hatjuk közvetlenül a lehetőségeinkről, elsők közt a WGÉPNÉV 
megadásával próbálkozzunk. A gonosz program még erősza- 
kos, mentési lehetőség nélküli újraindítást is támogat, a 
/C paraméterrel. Saját tapasztalat, hogy a lekapcsolás nem tel- 
jesen kompatibilis az ACPI/ATX alapú Windows 2000 gépek- 
kel, ezért a szokásos búcsúképernyő kinnt marad, és a tápot 
sem kapcsolja le. Feltehetőleg a program NT4-es múltjában 
van a bibi. A /R kapcsoló újraindítást eredményez a lekapcso- 
lás helyett, ez működik. A /T:xx használatával másodpercben 
megadható a figyelmeztetés és a kikapcsolás/újraindítás kö- 
zötti idő. Ez alapértelmezés szerint 30 másodperc. A kedvenc 
funkcióm azonban az üzenet-beszúrási lehetőség (, üzenet"), 
amivel is megfelelő haiku költeményeinkkel az öngyilkosság- 
ba kergethetjük felhasználóinkat. Talán csak a csoportos gép- 
kiválasztás hiányzik a repertoárjából. A shutdown.exe termé- 
szetesen időzíthető az AT vagy a Task Scheduler segítségével. 


A MICROSOFT MAGYARORSZÁG SZAKMAI MAGAZINJA 
2001. 04. 


RÉSZ) 





alol 


sor] 


IT Edágetestena Wihag Serro Data 


Paletta 2 O vettem by Steghen L. Bryant 3. 19931995 at Marozott. 
saga AUTOKAT] Morazer] [AJ [AJ [TA CVSTTT 





Domre resze. 
Úcosurem  Sosdhezarsmetői hatotta 
fronmak genti be pó stated mh 
ate cöer sztár, be) adbessed, 
I húdonm Me s orty pezsi árratte 
parod. 3 és szád usa, ad etter are gyrered, 
hk Socherthe bc hete that d vo usa ts parameter 
he rogy mát gyart ény elh 
m at be much shardé reboet alter dude. 
Me ss be tmer fa gyen n. 
Bose dia] 
maf am mátrai mestage, [max. 127 crartoró] 
ke Főeesi 12. 
ATTENTION 1 you usa the JC parameter NI grares the 
ale Tau ud se ro FieZave 


o Kérjük vigyázzanak, az ajtók záródnak! 


RDPCIlip - állományműveletek terminál-klienssel 

Windows 2000 Resource Kit 

Network Management Tools 

Megkérdőjelezhetetlenül nagy hiányossága volt az eredeti ter- 

minálszolgáltatás kliensének a kiszolgáló és a helyi gép közötti 

állományműveletek megoldatlan kérdése. Mi a helyzet ha SMB 
kapcsolat nélkül csatlakozom a kiszolgálóhoz? Ha más állomány- 
átviteli (FTP, WEB-DAV, stb) szolgáltatás nincs engedélyezve? 

Erre ad választ ez a hiánypótló kiegészítés, amely remélhetőleg 

a következő szervízcsomag részeként mindenhova el fog jutni. 

Egyelőre be kell azonban érnünk ezzel a körülményesen telepít- 

hető bővítéssel, és figyelembe kell vennünk, hogy a weben pub- 

likálható ActiveX TSAC-t nem támogatja, kizárólag a hagyomá- 

nyos klienst. Azonban megfelelően telepítve megoldja ezt a 

problémát, és immáron gondtalanul lehet másolgatni a klienst 

futtató gép és a kiszolgáló állományrendszere között. 

A kiegészítés egyaránt támogatja a 16 és a 32 bites kliense- 

ket, a kivágás, másolás és beillesztés funkciókat mind egyedi 

állományok, mind teljes könyvtárstruktúrák esetében is. A ha- 
gyományos Ctrl4C Ctrl:-V Ctrl:-X billentyűkombinációk tovább 
élnek, ugyanúgy, mint a Windows Explorer idevágó Copy, Cut, 

Paste utasításai. Ez a funkció a Windows 2000 terminálszolgál- 

tatás virtuális csatorna architektúrájának köszönhetően műkö- 

dik. A telepítéséhez kliens és kiszolgáló oldalon egyaránt kell 
változtatnunk a terminál-szoftveren. A kiszolgáló oldalán vagy 

a már feltelepített Resource Kit könyvtárából (egy terminál- 

kapcsolaton keresztül) futtassuk le az fxfrinst.bat parancsállo- 

mányt, vagy manuálisan tegyük meg a következő lépéseket: 

1. A WINNTNSYSTEM32 könyvtárban hozzunk létre egy RDP 
CLIP alkönyvtárat. 

2. Másoljuk ide a kicsomagolt Resource Kit könyvtá- 
rából az RDPClip.exe állományt. 

3. Egészítsük ki a regisztrációs adatbázist az fxfr.ini tartal- 
mával. Ezt manuálisan a regedit használatával, vagy a 
,regini fxfr.ini" paranccsal tehetjük meg. 

4.  Másoljuk a WINNTNYSTEM32 könyvtárba a kicsomagolt 
Resource Kit forrásból az fxfr.dil állományt. 


Kliensoldalon a Resource Kit könyvtárából először az fxfr.dll 
állományt kell bemásolni a Terminal Server Client könyvtárá- 
ba, ahol az mstsc.exe is található. Ez alapértelmezés szerint a 
c:AProgram FilesWerminal Server Client elérési úton találha- 
tó. Ezután az rdpdr.dll kerüljön szintén ugyanide, felülírva az 
eredeti rdpdr.dll-t. 
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Végül már csak a kiszolgáló és a kliens újraindítására van 
szükség. A dokumentációban egy nem létező, fxfr srv.reg 
nevű állományra hivatkoznak, amely valójában az fxfr.ini for- 
májában került fel a CD-re. (Hogy én ezzel mit kínlódtam! Na- 
tív spekulációval nem jutottam eredményre. Hiába no, olvasott 
embernek párja nincs :) - a szerk.) 


Windows 2000 Error and Event Messages Help 

Windows 2000 Support Tools 

Computer Management Tools 

W2000Omsgs.chm 

Egy átlagos, viszonylag problémamentes (most tessék leko- 
pogni) hálózat üzemeltetése során is rendszeresen találko- 
zunk hibaüzenetekkel, a lehető legváratlanabb helyeken, 
időnként meglehetősen abszurd tartalommal. Ezek megfejté- 
se erősen embert próbáló rendszerfelügyeleti munka. Azon- 
ban itt a varázslatos szótár, amely összefoglalja mindezt ka- 
tegorizálva, kereshetően. Az adott bejegyzés a hiba leírásán 
kívül tartalmazza a megoldási javaslatot. Természetesen nem 
kizárólagos forrásként kezelendő, a különböző Technet és tu- 
dásbázis (KB) cikkek legalább annyira vonatkozóak lehetnek. 
És nemcsak az Eseménynapló bejegyzéseire hegyezték ki - a 
legtöbb gyári Windows alkalmazásra és parancsra vonatko- 
zóan van bejegyzés. Legyen az Backup vagy Terminal Servi- 
ce, esetleg netstat vagy route, bejegyzések bőven állnak ren- 
delkezésünkre. Még Marcell kedvenc Network Monitorjáról is 
találtam ezt-azt. Nem állítom hogy automatikusan mindenre 
választ kaphatunk itt, de segítségével legalább eggyel több 
esélyünk van a lelki békére. 
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Hálózati kapcsolat vizsgálata: Netdiag.exe 

Windows 2000 Support Tools 

Diagnostic Tools 

A Windows 2000 igen megbízható hálózati implementációjá- 
nak és beállításainak (protokollok, kártyák és szolgáltatások) 
működésével ritkán akad baj. Ha viszont problémák vannak, 





SZERSZÁMOSLÁDA (I. RÉSZ) 
általában rejtélyes, nehezen debuggolható ügyben küzdel- 
met kell vívnunk a rendszerrel. Van hogy egy eszközmeghaj- 
tó kavarja össze életünket, van hogy a kiszolgálók szolgálta- 
tási oldalán nincs valami rendben. A program paraméterezés 
nélkül futtatva is max 5 másodpercig dolgozik, ekkor minden 
alapvető teszt lefut. Ezáltal könnyen kiokíthatjuk akár fel- 
használóinkat is a parancs egyszerű futtatására, amelyből 
gyorsan kiderül, hogy mi nem stimmel. A teljes tesztfelsoro- 
lás helyett most kiemelnék néhány fontosabb vizsgált ténye- 
zőt: DNS, WINS kiszolgálók, Kerberos, NDIS, Winsock, alapértel- 
mezett átjáró. Ellenőrzi a gép tartomány-tagságát, valamint 
a WAN paramétereket is egyből kezeli. Az összes egyenérté- 
kű információ kinyeréséhez 5-10 különböző parancsot kéne 
egy-ébként kiadnunk (ipconfig -all; ping dns.domain.hu; 
ping gateway.domain.hu; stb), vagy külön hardvertesztelő esz- 
közt bevetni (lásd NDIS teszt). Használatának alapfeltétele 
legalább egy hálózati eszköz, amely TCP/IP csatolással rendelke- 
zik. Emellett vizsgálja az IPX kapcsolatot is, valamint Netware 
kliens esetében az NDS vagy bindery bejelentkezést. Hihetetlen, 
de mindemellett még Microsoft multiplatformos is, Windows 95, 
98 és NT 4.0 rendszereken is működik a Windows 2000 mellett. 


he Lgz 
1 NetBt transpao 


CG tás 


IP loopback ping test 


5 Hálózati kapcsolatunk szép és egészséges 


Következő alkalommal a címtárak felé evezek, az AD és a 
hozzá kapcsolódó területekről (LDAP, ADSI) választok né- 
hány segédprogramot. 


Radvánszki Gábor, MCP 
rgabor€osved.net 


A cikkben szereplő URL-ek: i 


[1] http://msdn.microsoft.com/subscriptions/resources/subdwnld.asp 
[2] http://www.microsoft.com/windows2000/library/resources/reskit/tools/default.asp 
[3] http://windows.microsoft.com/windows2000/en/server/iis/htm/core/iicodira.htm 
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a . Exchange 2000-ben 


Az Interneten zajló levelezés alapja az SMTP Protokoll (Simple 
Mail Transfer Protocol). A Microsoft Exchange Server mindig is 
képes volt üzeneteket küldeni más SMTP kiszolgálóknak: az In- 
ternet Mail Connector (IMC) egy opcionális kiegészítő komponens 
az Exchange Server 4.0 rendszerhez, az Internet Mail Service 
(IMS) pedig valamennyi Exchange Server 5.0 és 5.5 kiszolgáló- 
ban megtalálható kiegészítő. Bár könnyen telepíthető az IMS, 
az SMTP az Exchange Server korábbi verzióiban nem játszott 
kulcsszerepet. Az IMS hasonlít a többi csatolóhoz, amelyekkel 
más levelezőrendszerhez (pl. Lotus Notes, cc:Mail, IBM PROFS) tud- 
juk csatlakoztatni az Exchange kiszolgálónkat, és szorosan együtt- 
működik az X.400-alapú Message Transfer Agenttel (MTA), mely 
az üzenetek vállalaton belüli irányításáért felelős. Az útválasz- 
tófolyamat felelős az üzenet címzettjének meghatározásáért, és 
az üzenet rendszeren belüli és azokon kívüli leghatékonyabb to- 
vábbításáért. Az Exchange Server 5.5-ös és korábbi verzióiban 
ezt a feladatot az MTA látta el. Az Exchange 2000 Server rend- 
szerben teljesen új, SMTP alapú útválasztás jelent meg. 

Az az architektúra, mely a különböző csatolókat az MTA köré 
fogta össze az Exchange Server kezdeti verzióiban akkor jelent meg, 
amikor az X.400 volt az üzenetküldés ipari szabványa. Mostanra 
az SMTP foglalta el a helyét -pontosabban annak továbbfejlesz- 
tett, napjaink legjelentősebb üzenetkezelő rendszerei által alkalmazott 
verziója. Az SMTP az Exchange 2000 üzenettovábbító rendszeré- 
nek alapja, mely az Exchange Server korábbi verzióiról történő 
átállás során is biztosítja a levelezés folyamatos működését. 
Az Exchange 2000 ismertetése előtt fontos megvizsgálni az 
SMTP történetét és fejlődését, integrálódását az Exchange Ser- 
ver rendszerrel, útválasztó és adminisztrációs szabályait, vala- 
mint jövőjét az üzenettovábbítás területén. Ismerni kell továb- 
bá, hogy az útválasztócsoportok miként fogják logikai csopor- 
tokba az egyes kiszolgálókat az üzenetküldés folyamatához. 


Az SMTP története és fejlődése 

Az IETF 1982-ben definiálta az SMTP jellemzőit a 821-es és 
822-es ajánlásokban (RFC). Nevének megfelelően az SMTP ere- 
deti verziója egyszerű volt, a fő cél sima 7-bites karakterkész- 
letű szöveges üzenetek küldése egy kiszolgáló és egy ügyfél 
közt. Az SMTP műveletek alapértelmezett portja a 25-ös lett. 
1982 óta az SMTP folyamatosan fejlődött, hogy napjaink mo- 
dern üzenettovábbítási követelményeinek megfeleljen. Érthe- 
tő okokból a fejlődés az Internet terjedésének hatására az el- 
múlt években különösen felgyorsult. A két legfontosabb újí- 
tás, melyek segítségével az SMTP a legmodernebb igényeket 
is képes kielégíteni a továbbfejlesztett SMTP (Extended SMTP, 
ESMTP) és a MIME (Multipurpose Internet Mail Extension), 
melyről e lapszámunk 33. oldalán bővebben is olvashat. 


ESMTP 

Az ESMTP lehetővé teszi, hogy a gyártók az alap SMTP szol- 
gáltatást kiegészítőkkel lássák el, mely így képessé válik 
különböző új üzenettípusok és funkciók kezelésére. Az Ex- 
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change Server 5.5 is támogatja az ESMTP-t, mivel lehető- 
vé teszi az Internetszolgáltató  levelezőrendszerén lévő 
üzenetek egyszerűbb átvételét. Erre akkor van szükség, ha 
valaki az Internethez egy szolgáltatón keresztül csatlako- 
zik, és nem rendelkezik folyamatos kapcsolattal. A szolgál- 
tató tárolja a leveleket, melyeket később az Exchange se- 
gítségével le lehet tölteni, és szét lehet osztani a helyi fel- 
használók között. Az Exchange Server korábbi verziói támo- 
gatnak néhány ESMTP parancsot. Például az SMTP telefonos 
hálózaton történő használatához az Exchange Server 5.5 tá- 
mogatja az ETRN parancsot, mely az üzenetsorok kezelését 
is egyszerűsíti. Az Exchange Server és más SMTP kiszolgá- 
lók közötti hitelesített és titkosított kapcsolat támogatásá- 
hoz az Exchange Server 5.5 Service Pack 2 (SP2) és későb- 
bi verziói ismerik az AUTHALOGIN, STARTTLS, és TLS kiegé- 
szítéseket. Egy SMTP kiszolgáló által nyújtott ETRN támoga- 
tás szintje könnyen meghatározható, ha telnet programmal 
a kiszolgáló 25-ös portjára csatlakozunk, majd kiadjuk az 
EHLO parancsot. A kiszolgáló ekkor megjeleníti az általa tá- 
mogatott kiterjesztések kulcsszavait. Az első kép az Ex- 
change Server 5.5 SP3 által nyújtott, a második az Exchan- 
ge 2000 által biztosított kiterjesztéseket mutatja. A legfon- 
tosabb új kiegészítések a CHUNKING, PIPELINING, DSN, és 
a X-LINKZSTATE (melyről a későbbiekben még szó lesz). 








5 Az Exchange Server 5.5 SP3 SMTP tudása 








5 Az Exchange 2000 SMTP tudása 


2 A Chunking támogatja a stream-módú adatátvitelt, vagyis 
az Exchange 2000 nemcsak soronként képes üzeneteket 
küldeni és fogadni, hanem bináris adatként is. A korábbi 
SMTP kiszolgálók, mint az IMS, az SMTP üzeneteket sorok- 
ból álló szövegként kezelték, nem összetett struktúraként, 
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mint azt ma látjuk. Az üzenetek bináris alapon történő 
kezelése teljesítményszempontok miatt fontos - különö- 
sen az egyre növekvő csatolt fájloknál. 

0 A Pipelining is a teljesítményt növeli. Ennek révén az 
SMTP kiszolgáló több parancsot adhat ki egyszerre, nem 
kell várakoznia minden egyes parancs visszaigazolására. 

-0 A Kézbesítési állapot értesítés (Delivery Status Notifica- 
tion, DSN) lehetővé teszi, hogy az Exchange 2000 szab- 
ványos értesítést küldjön a felhasználónak a kézbesítés 
sikerességéről. Ezek az értesítések veszik át az Exchange 
Server 5.5-ben megjelenő nem szabványos hibajelzése- 
ket, melyeket egy üzenet sikertelen kézbesítése okozott. 


MIME 

Az egyszerű szöveges üzenetek unalmassá válhatnak, főként 
napjaink grafikus világában. A korai kódolási eljárások, mint 
a UUencode lehetővé tették csatolt fájlok és formázott szö- 
vegek küldését, de ezek a lehetőségek rendszerint nem vol- 
tak egységesen integrálva. Továbbá a különböző csatolt fáj- 
lok által használt formázó jeleket pontosan be kellett állíta- 
ni, hogy a fogadó fél értelmezni tudja azokat. 

A MIME megoldja ezt a problémát, mivel szabványos címkék 
segítségével szabályozza az üzenetekben lévő különböző tí- 
pusú adatok jelölését és továbbítását. Alapvetően a MIME 
azt mondja meg a levelezőrendszernek, hogy az miként dol- 
gozza fel az üzenet egyes részeit, hogy a fogadó pontosan 
azt kapja meg, amit a küldő neki szánt. Talán használta már 
a MIME-t Microsoft Word dokumentumok vagy Microsoft Po- 
werPoint prezentációk küldésére. A MIME az alapja az audio- 
és videoanyagok üzenetként történő küldésének is, melyek 
általában sokkal nagyobbak, mint a dokumentumok vagy pre- 
zentációk. Híres példa a Baljós Árnyak (Phantom Menace) 25 
Gigabájtos előzetesének esete, mely sok levelezőrendszert 
terhelt le a végsőkig, amikor a felhasználók elkezdték azt 
egymásnak küldözgetni. A csatolókon alkalmazott korlátozá- 
sok megakadályozzák nagyméretű csatolt állományok küldé- 
sét más cégek felhasználóinak, ugyanakkor a nagy üzenetek 
a belső levelezésben is gondokat, késedelmet okozhatnak. A 
rendszergazdák jogosan tartanak attól a terheléstől, amit a 
nagy üzenetek jelentenek a kiszolgálóknak, ezért próbálják 
lebeszélni a felhasználókat a nagy hang- és mozgókép üze- 
netek küldéséről. Ennek ellenére a nagy csatolt fájlok a jö- 
vőben egyre gyakoribbak lesznek, számítani kell arra, hogy 
hálózaton egyre több nagyméretű csatolt fájl lesz jelen. 


Az SMTP és az Exchange 2000 

A Microsoft az Exchange 2000 fejlesztésénél minden, kiszol- 
gálók közti kommunikációt SMTP alapon szervezett meg - 
ez radikális változtatás az addig használt távoli eljáráshí- 
váshoz (remote procedure calls, RPCs) képest. Az RPC-vel 
történt szakítás helyes döntés volt. Amikor működik, a tá- 
voli eljáráshívás remek eszköz, de nagy sávszélességet igé- 
nyel a folyamatos használata. Amikor nem működik, hatal- 
mas üzenetsorok gyűlnek fel nagyon gyorsan. Az RPC-k mel- 
lőzése része az Exchange 2000 fejlesztése során tapasztal- 
ható általános tendenciának, hogy a Microsoft-specifikus 
protokollokat szélesebb körben használt Internetes proto- 
kollokra cseréljék le. Az Exchange 2000 csak akkor használ 
RPC-t, amikor vegyesmódú hálózatban másik kiszolgálóhoz 
csatlakozik. (Vegyesmódú hálózatban mind Exchange 2000, 
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mind korábbi verziók megtalálhatók.) Ez logikus, mivel az 
RPC jelenti az egyetlen protokollt, melyet minden Exchan- 
ge kiszolgáló garantáltan ismer. 

Az Exchange Server korábbi verzióiban az SMTP támogatást 
külön kellett telepíteni és beállítani. Az Exchange 2000 kiszol- 
gálóknál az SMTP már automatikusan telepítésre kerül. Alap- 
vetően minden Windows 2000 (Win2K) kiszolgáló telepíti az 
SMTP szolgáltatás egy egyszerű fajtáját, így az alkalmazások 
adatokat cserélhetnek a kiszolgálók közt. A Win2K ezzel is vé- 
gezheti a kiszolgálók közti Active Directory replikációt. Az Ex- 
change 2000 telepítése során az alap SMTP szolgáltatás szá- 
mos új elemmel bővül, mint az Exchange Information Store- 
ba (levelesládákba) történő kézbesítés, vagy a fejlett üzenet- 
sor-kezelési mechanizmus. Technikailag az Exchange 2000 
frissíti az SMTP szolgáltatást, mely így a Collaboration Data 
Objects (CDO) 3.0-s verzióját is támogatni képes a 2.0 verzión 
túl. A fejlett üzenetsor-kezelési mechanizmus korlátozások 
bevezetését teszi lehetővé (mind a levelesládákra, mind a csa- 
tolókra). Az első Exchange 2000 kiszolgáló telepítése frissíti 
az Active Directory sémáját, hogy - többek között - az új 
megszorításokhoz szükséges attribútumokat támogassa. Az 
Exchange Server 5.5 által támogatott levelesláda-kvótán kívül 
mostantól meghatározható például, hogy a nagy méretű üze- 
netek mely időpontokban haladhatnak át egy csatolón. 

Az operációs rendszer és a levelezőrendszer szoros integrá- 
cióját mutatja az a tény is, hogy az Exchange 2000 csak ki- 
terjeszti, de nem újratelepíti a Win2K meglévő, alapszintű 
SMTP szolgáltatását. Bár az Exchange Server 5.5 és a Win- 
dows NT közt is szoros a kapcsolat, az Exchange 2000 és a 
Win2K számos más ponton is kapcsolódik egymáshoz. Ez a 
sok összekapcsolódás meg is nehezítheti a rendszer felügye- 
letét, és a folyamatok részletes ismeretét teszi szükségessé. 
Az Exchange 2000 rendszer sikeres üzemeltetéséhez tisztá- 
ban kell lenni valamennyi függőséggel és kapcsolattal. 


ETTE a 1! 212 


General] LogOn] Recovery. Dependencies ] 


Some services depend on other services. If a service is stopped or is not 
tunning properly, dependent services can be affected. 











5 SMTP Tulajdonságok 


A fenti ábra mutatja, hogy az SMTP szolgáltatáshoz szükség 
van a Microsoft Internet Information Services (IIS) szolgál- 
tatásra is. Az IIS problémái befolyásolhatják az SMTP szol- 
gáltatást is. Hasonlóképpen, ha az SMTP szolgáltatással 
gond van, elképzelhető, hogy nem lesz képes üzeneteket 
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küldeni más Exchange kiszolgálóknak, vagy a külvilágnak. Az 
SMTP hibás működése más alkalmazásokat is érinthet. Például 
a címtárak közti replikáció leállhat, ha egy tartományvezérlő 
SMTP beállításai hibásak, mivel a Win2K telephelyek közti 
replikáció SMTP üzenetek segítségével is történhet. 


Virtuális kiszolgálók 

A Win2K-ban az internetes protokollok - HTTP, az SMTP, a 
POP3, és az Internet Message Access Protocol 4, (IMAP4) - az 
IIS 5.0-be vannak integrálva, és így mindegyik protokollal 
létre lehet hozni virtuális kiszolgálót. Egy virtuális kiszolgálót 
felfoghatunk úgy, mint a protokoll, a port és a konfigurációs 
adatok összessége. Egy gépen több virtuális kiszolgáló futtat- 
ható, vagyis egy Exchange 2000 kiszolgálón akár több virtuá- 
lis SMTP szerver is működhet egyszerre. Az alaphelyzet szerin- 
ti virtuális kiszolgáló a 25-ös portot használja, de a többi vir- 
tuális kiszolgáló akár más porton is működhet, illetve egyéb 
más beállítások adhatók nekik. Ez a funkció lehetővé teszi, 
hogy egy Exchange 2000 kiszolgáló számos különböző típusú 
és igényű e-mail tartomány levelezését lássa el, és erre az 
Internetszolgáltatóknak nagy szükségük is van. Továbbá az 
Exchange 2000 támogatja több SMTP csatoló (SMTP Connec- 
tor) kialakítását egyetlen virtuális kiszolgálón. Ha az IMS-t is 
egy SMTP csatolónak tekintjük, akkor az Exchange 5.5 eseté- 
ben egy gépen csak egyetlen SMTP csatoló lehet, de az Ex- 
change 2000 segítségével több csatoló állítható be, minde- 
gyik különböző célra. Például az egyik csatoló a levelek belső 
hálózatra történő irányításért felel, egy másik pedig a kime- 
nő leveleket egy Smart Host felé irányítja, ahol a levelek ví- 
rusellenőrzésen esnek át, mielőtt az Internetre kerülnének. 


Az üzenetkezelés adminisztrációja 

Az Exchange Server 5.5 a kiszolgálókat telephelyekbe (site) fog- 
ja össze - mely egy vagy több, helyi hálózatnak megfelelő sáv- 
szélességen csatlakozó kiszolgálót tartalmaz. A telephelyek ösz- 
szessége alkotja a szervezetet (organization) , egy felügyeleti egy- 
séget alkotva, mely megosztott címtárral és konfigurációval ren- 
delkezik. A szervezeti koncepció megmaradt az Exchange 2000 
rendszernél is. Egy Win2K hálózatban csak egyetlen Exchange 
2000 szervezet létezhet, mivel az Active Directoryban a közösen 
használt konfigurációs partícióban az Exchange szervezetek 
konfigurációs adatai részére egy tároló hely van fenntartva. 

A Win2kK terminológiája a telephely (site) kifejezéssel a közös 
hálózaton osztozó kiszolgálókat jelöli - ebben az esetben egy 
vagy több IP alhálózat alkotja a hálózatot. A Win2K telephe- 
lyek sokkal szorosabban kapcsolódnak az alacsonyabb hálóza- 
ti rétegekhez, mint az az Exchange Server 5.5 telephelyek 
esetén volt. Kicsi az esélye annak, hogy olyan Win2K telephe- 
lyet találnánk, mely az egész világot átfogja, ugyanakkor szá- 
mos ilyen Exchange Server telephelyről tudunk. A Win2K te- 
lephelyek kialakításának nincs olyan közvetlen adminisztratív 
következménye, mint az Exchange Server 5.5 telephelyeknek, 
amelyek egyben az adminisztrációs, biztonsági és replikációs 
műveletek határait is jelentik. 

Az Excange 2000-ben az adminisztrációs és útválasztó csopor- 
tok (administrative group, routing group) váltották fel az Ex- 
change Server 5.5 telephelyeit. Az adminisztrációs csoport je- 
lenti a felügyeleti műveletek kereteit. A rendszergazda egy 
adminisztrációs csoportba tartozó valamennyi kiszolgáló 
felügyeletéért felelős. Az útválasztó csoportok határozzák 
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meg, hogy az üzenetek milyen útvonalon közlekedjenek a 
szervezet kiszolgálói közt. Egy útválasztó csoporton belül bár- 
mely kiszolgáló igény szerint pont-pont kapcsolatot alakíthat 
ki egy másik kiszolgálóval, pontosan úgy, ahogy az Exchange 
5.5 telephelyben a kiszolgálók csatlakoznak egymáshoz. Ve- 
gyes módú Exchange szervezetben az adminisztrációs csopor- 
tokon belüli útválasztó csoportok felelnek meg az Exhange 5.5 
telephelyeknek, azaz az Exchange 2000 úgy láttatja a saját 
csoportosításait az Exchange 5.5 kiszolgálók számára, mintha 
a telephely-modellt használná, mivel a korábbi kiszolgálók 
nem ismerik az adminisztrációs és az útválasztó csoportot. Ké- 
sőbb, amikor minden kiszolgálón az Exchange 2000 fut, a szer- 
vezet natív módba kapcsolható, és az útválasztó csoportokból 
új struktúra alakítható ki, például olyan, hogy egy útválasztó 
csoport más adminisztratív csoport kiszolgálóit is tartalmazza. 
A telephelyek nagyon hatékonyak kis szervezeteknél, ahol a 
rendszergazda feladata tipikusan a felügyelet és az irányítás 
figyelése. Nagyobb szervezeteknél azonban gyakran külön cso- 
portok felelősek a kiszolgálók felügyeletéért és a levelezés biz- 
tosításáért. Jó hír, hogy amennyiben a vállalat működése azt 
sugallja, akkor az Exchange 2000 pontosan úgy felügyelhető, 
mint az Exchange Server 5.5. Az Exchange 2000 alkalmazásá- 
val azonban lehetőség van arra is, hogy a felelősséget külön- 
böző csoportok közt osszuk szét. Az adminisztrációs feladatok 
hatékonyabb szétosztása kiemelt fontosságú a Win2K rendsze- 
rekben. Ezért készítette el a Microsoft a Microsoft Management 
Console (MMC) keretrendszert, melynek segítségével testre 
szabott konzolok készíthetőek a szükséges komponensekből. 
Sok nagy társaság több szinten üzemelteti a számítógépes 
rendszert. Az Exchange Server 5.5 egyetlen, mindenki által 
használható egyszerű eszközt biztosít - a Microsoft Exchange 
Administrator programot. Általában kényelmes megoldás 
ugyanazt az eszközt használni minden feladatra, de miért kel- 
lene ágyút adni annak a kezébe, aki csak egy verébre lő (egy 
felhasználó adatait szeretné megváltoztatni, hozzá kell férnie 
egy összetett komponens beállításaihoz stb.)? 

Az alábbi ábra az Exchange 2000 System Managert mutatja, 
egy MMC konzolt, mely számos bővítményt tartalmaz. Ez az 
eszköz hasonlítható leginkább az Exchange Administratorhoz. 
Valójában az egyes bővítmények akár különböző üzemeltetői 
csoportokhoz rendelhetők. Az ábrán az adminisztrációs és út- 
választó csoportok közti kapcsolat látható. Egy adminisztrá- 
ciós csoport tipikusan nagyobb területet ölel fel, mint egy út- 
választó csoport. Ebben a példában két adminisztrációs cso- 
port felügyel egy hálózatot, és mindegyik rendelkezik egy 
vagy több útválasztó csoporttal. 
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Útválasztó csoportok 

Minden kiszolgáló, ami egy útválasztó csoportba tartozik au- 
tomatikusan képes egymással kommunikálni. Ez így volt az Ex- 
change Server 5.5 telephelyeknél is, de itt a kiszolgálók más- 
ként kommunikálnak. Emlékeztetőül, az Exchange Server 5.5 
kiszolgálók távoli eljáráshívást alkalmaznak, míg az Exchange 
2000 esetében a kiszolgálók SMTP használatával, alapesetben 
a 25-ös porton kommunikálnak. A másik alapvető különbség 
az Exchange Server 5.5 és az Exchange 2000 közt, hogy Ex- 
change Server 5.5 esetén a kiszolgálók közti címtárreplikáció 
teszi ki a forgalom jelentős részét, míg Exchange 2000 kiszol- 
gálóknál a forgalmat csak a felhasználók személyes üzeneti és 
a nyilvános mappák replikációs üzenetei alkotják, mivel az 
Exchange 2000-nek nincs önálló címtáruk, az Active Directo- 
ry-t használják. Az Exchange 2000 kiszolgálók csak a hálózat 
állapotát leíró kis adatcsomagot küldenek egymásnak, de ez 
jóval kisebb forgalmat jelent, mint a telephelyek címtárrepli- 
kációja. A címtár frissítése most az Active Directory feladata. 


Az útválasztó csoportok csatlakoztatása 

Útválasztó csoportok csatlakoztatása az SMTP csatoló, az 
X.400 csatoló, vagy Routing Group Connector (RGC) alkalma- 
zásával történhet. Bizonyos szempontból az RGC megfeleltet- 
hető az Exchange Server 5.5-ben alkalmazott távoli eljárás- 
hívás alapú Site Connectornak. Az RGC-t egyszerű telepíteni 
és beállítani. A Site Connectorral ellentétben az RGC széle- 
sebb körű beállítási lehetőségeket biztosít a levéltovábbítás- 
ban résztvevő kiszolgálók felett. A Site Connector segítségé- 
vel egy telephely valamennyi kiszolgálójának vagy egy meg- 
nevezett hídfőkiszolgálónak (bridgehead server) a forgalmát 
lehet szabályozni. Az RGC lehetővé teszi, hogy bármennyi ki- 
szolgáló hídfőként működjön. Az RGC továbbá beállítható 
úgy, hogy a csatolókat csak bizonyos felhasználók használ- 
hassák, a csatolón átmenő forgalom prioritása is hangolható 
(pl. magas, közepes, alacsony). Ezen kívül lehetőség van idő- 
zítések megadására, hogy a nagy üzenetek mikor haladhas- 
sanak át a csatolón, így a nagy csatolt állományok nem aka- 
dályozzák a normális üzleti forgalmat. 

Az RGC az SMTP forgalmat kezeli, és egy virtuális SMTP ki- 
szolgáló felett fut. Az RGC egyirányú csatoló, az üzenetek 
mindkét irányba történő közvetítéséhez először külön be kell 
állítani mindkét oldalt. Ha a megcélzott útválasztó csoport- 
ban adminisztrátori jogosultsággal rendelkezünk, a kapcsolat 
mindkét oldala egyetlen lépéssel beállítható. 

Az alábbi ábra mutatja a Budai Igazgatóság és a Pesti igaz- 
gatóság útválasztó csoportot összekötő RGC kapcsolat tulaj- 
donságait. A Do not allow public folder referrals (Nyilvános 
mappára történő hivatkozás tiltása) jelölőnégyzet igen fon- 
tos. Alapesetben ez nincs kiválasztva, tehát a felhasználók 
ezen a csatolón keresztül másik útválasztó csoportban lévő 
nyilvános mappákhoz is hozzáférhetnek. Az Exchange 2000- 
ben a , hivatkozások" lépnek az Exchange Server 5.5 alatt al- 
kalmazott nyilvános mappa , affinitás" koncepció helyére, és 
most az útválasztó csoportok vették át a telephelyek szere- 
pét. Amikor a felhasználó egy nyilvános mappához kíván 
hozzáférni, az Exchange 2000 először a felhasználó postalá- 
dáját tároló kiszolgálón beállított nyilvános mappa kiszolgá- 
lón próbálja elérni a nyilvános mappa egy példányát. Ha ott 
nem talál ilyet, az Exchange 2000 a felhasználó útválasztó 
csoportjával azonos csoportban lévő kiszolgálóknál próbálko- 
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zik. Ha ott sem talál másolatot, az Exchange 2000 a legala- 
csonyabb költségű csatolón keresztül csatlakozik egy másik 
útválasztó csoporthoz, és ott próbálkozik. Minden csatoló 
rendelkezik egy költségtényezővel (1-től 100-ig) ami a kap- 
csolat (hálózati értelemben vett) költségét jelzi egy hídfőhöz 
való csatlakozáskor. Az alacsonyabb költségű útvonalak 
előnyt élveznek. Az alábbi ábrán látható RGC-nél a csatoló 
költsége 1, ami a lehető legalacsonyabb érték. Ez a csatoló 
egy preferált irány egy nyilvános mappa másolatához, ha az 
a Pesti Igazgatóság útválasztó csoportban megtalálható. 
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Ha az RGC SMTP-t használ, miért van szükség külön SMTP 
csatolóra? A válasz egyszerű - az Exchange 2000 rendsze- 
rek egy kicsi részét képezik az SMTP-t használó kiszolgá- 
lóknak. Az emberek más SMTP-t használó rendszerekkel is 
kommunikálni akarnak, és ezt olyan egyszerűen szeretnék 
tenni, ahogyan csak lehet. 

Az RGC-hez hasonlóan az SMTP csatoló is egy virtuális SMTP 
kiszolgáló felett fut. Míg az RGC az Active Directory adatait 
használja az üzenetek irányításához, addig az SMTP csatoló 
olyan szabványos SMTP útválasztó technikákat alkalmaz, 
mint a névkiszolgálók (DNS) levéltovábbítási (mail exchan- 
ger, MX) rekordjai. Ezért, ha a leveleket Smart Host rendszer- 
hez szeretnénk irányítani, vagy MX rekord alapú irányítást kí- 
vánunk alkalmazni, vagy csak egyszerűen üzeneteket kívá- 
nunk küldeni az Exchange kiszolgálón túlra (beleértve a ko- 
rábbi Exchange kiszolgálón futó IMS rendszereket is), akkor 
szükségünk van egy SMTP csatolóra. 

Az alábbi ábra egy SMTP csatolót mutat. Ez a csatoló vala- 
mennyi üzenetet az smtpgate.igsoft.hu címre irányítja. A 
Smart host olyan levelező-kiszolgáló, mely legtöbbször az 
adott vállalat SMTP levelezésének központja. Az üzenetek 
kézbesítés előtt egy helyre történő összegyűjtése lehetősé- 
get biztosít pl. vírusellenőrzésre. A Smart host továbbá lehe- 
tővé teszi annak ellenőrzését, hogy a felhasználók betartják 
a vállalati szabályokat (pl. általános információk fűzése a le- 
vélhez, bizalmas adatok küldésének megakadályozása, stb). 
A MiMEsweeper (http://www.mimesweeper.com) egy nép- 


szerű példája a smart hostokon futó szoftvereknek. 
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a SMTP csatoló 


Valamennyi üzenet Smart host-hoz történő irányítása csak az 
egyik beállítási lehetőség. További beállítások adhatók meg 
az SMTP csatoló címtér (Address Space) tulajdonságlapján, 
ahol megadhatjuk, hogy az Exchange 2000 mely SMTP tarto- 
mányokat érje el az adott csatolón keresztül. Alapértelmezés- 
ben ez csillag ("), vagyis az Exchange 2000 minden tarto- 
mányt elérhet. Néhány esetben hasznos lehet, ha az Exchan- 
ge 2000 egyes tartományok üzeneteit egyedi módon kezeli. A 
következő ábra mutatja egy adott tartományhoz (pl. igsoft.hu) 
rendelt címtér beállításokat. Ezzel a beállítással a csatoló csak 
az igsoft.hu-hoz tartozó címeket kezeli, a többi üzenetnek 
más útvonalat kell találnia. Az ábra alján látható, hogy az Ex- 
change 2000 miként kezeli a csatoló hatáskörét. Az Exchan- 
ge Server 5.5 vezette be a csatoló hatásköre (Connector 
scope) fogalmat, ami egy csatoló elérhetőségét jelöli más ki- 
szolgálók számára. Az Exchange Server 5.5-ben a csatolók 
elérését terület, tartomány vagy szervezeti alapon lehetett 
korlátozni. Az Exchange 2000 esetében a megszorítás útvá- 
lasztó csoportra vagy az egész szervezetre állítható be. Az 
ábrán a csatoló csak az azonos útválasztó csoportba tartozó 
kiszolgálók számára érhető el. 
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Kapcsolatállapot alapú útválasztás 

A csatoló egyszerűen egy kapcsolat egy útválasztó csoport és 
más útválasztó csoport vagy más típusú rendszerek közt. Egy 
vállalaton belül több útválasztó csoport és csatoló működhet, 
Azért, hogy az üzenetek irányítása hatékony legyen, egy 
olyan mechanizmusra van szükség, ami a kiszolgálókat infor- 
málja a többi kiszolgáló és csatoló pillanatnyi állapotáról. 
Egy szervezeten belüli útvonalak nyilvántartásához az Exchan- 
ge Server 5.5 a Gateway Address Routing Table-t (GWART) 
alkalmazza. A Relative Identifier (RID) kiszolgáló (tipikusan 
ez az elsőként telepített kiszolgáló) felépíti a GWART-ot a szer- 
vezetben replikálódó címtáradatok alapján. A telephely többi 
kiszolgálója közösen használja a GWART-ot, így minden ki- 
szolgáló rendelkezni fog az üzenetek hatékony irányításához 
szükséges információkkal. 

Az Exchange Server 1996 óta ezt a modellt követte. A GWART 
nagyon sikeres, de statikus jellege komoly hátrányt jelent. A 
GWART akkor működik hatékonyan, ha a hálózat stabil, a ki- 
szolgálók és csatolók kiszámítható módon viselkednek. Ha 
nem kiszámítható faktorok jelennek meg az irányításban, ak- 
kor a GWART hatékonysága csökken, és a téves irányítások szá- 
ma növekedni kezd. A téves irányítás nem jelenti az üzenet el- 
vesztését, azonban az üzenet zsákutcába kerülhet. Ekkor újra 
kell irányítani, hogy végső céljába jusson. Az újrairányítás drá- 
ga és lassítja az üzenet kézbesítését, tehát kerülendő. 

Mivel a stabil hálózati környezet nem mindig megvalósítható, 
dinamikusabb módszerre van szükség a kiszolgálók értesítéséhez 
a hálózat aktuális állapotáról és az elérhető útvonalakról. Az 
Exchange 2000 kapcsolatállapot alapú útválasztást (Link State 
Routing, LSR) alkalmaz. Az LSR segítségével a kiszolgálók érte- 
sítik egymást a hálózati kapcsolatokban és csatolókban bekö- 
vetkező változásokról. Ezek az információk gyorsan eljutnak más 
útválasztó csoportokhoz is, így az egész szervezet összes kiszol- 
gálója mindig pontos képpel rendelkezik a hálózat állapotáról. 
Tegyük fel, hogy egy hálózati hiba miatt egy útválasztó cso- 
porthoz való csatlakozás meghiúsul. Egy perc múlva a hídfő- 
kiszolgáló újból megpróbál a távoli útválasztó csoport hídfő- 
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kiszolgálójához csatlakozni, hogy kiderítse, vajon a hiba át- 
meneti volt-e. Ha a csatlakozás nem sikerül, a hídfőkiszolgá- 
ló még kétszer próbálkozik, mielőtt rögzítené hogy a problé- 
ma tartós. A kiszolgáló végül , belátja", hogy a vonal nem 
működik, és a 691-es porton keresztül csatlakozik saját útvá- 
lasztó csoportjának főnökéhez (Routing Group Master, RGM). 
Minden csoportban van egy útválasztó csoport vezérlő, amely 
az útválasztó csoportba tartozó kiszolgálók információit 
gyűjti össze, és tartja a kapcsolatot a távoli útválasztó cso- 
portokkal. Ezen adatok alapján az RGM felépíti a Link State 
Table-t (LST), mely a hálózat aktuális állapotát tartalmazza. 
Az RGM tipikusan az útválasztó csoport elsőként telepített 
gépe, de az Exchange System Manager segítségével ez a sze- 
rep könnyen átruházható, mit azt az alábbi ábra is mutatja. 
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5 Ki legyen a Routing Group Master? 


Miután az RGM értesült a meghibásodott kapcsolatról, módo- 
sítja az LST-t, és tájékoztatja a változásról az útválasztó cso- 
port többi kiszolgálóját. Még egyszer: a kommunikáció a 
691-es port-on keresztül, speciális LSA protokollal történik, 
melyet a Microsoft direkt erre a célra fejlesztett ki. Az 
Exchange 2000 egy X-LINKZSTATE nevű ESMTP parancsot 
használ a kapcsolatállapotok információinak frissítésére az 
útválasztó csoportok közt RGC és SMTP kapcsolóknál 
egyaránt. Az Exchange 2000 a frissítéseket a hídfőkiszolgá- 
lóknak küldik, melyek azokat továbbítják az útválasztó cso- 
port vezérlőknek (RGM). Az Exchange 2000 a frissítéseket al- 
kalmazásspecifikus formátumban is tudja küldeni X.400 csa- 
tolókon keresztül. A továbbított adat nagyban tömörített, 
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így az Exchange 2000-nek csak egy pár másodpercre van 
szüksége, hogy továbbítsa az adatokat és az útválasztó cso- 
port számára elkészítse az új LST-t. Új kiszolgálók vagy kap- 
csolatok telepítése szintén kapcsolatállapot frissítést ered- 
ményez. 

A kapcsolatállapot frissítések gyorsan végbemennek az egész 
szervezetben. A cél az, hogy bármely kiszolgálót pár perc 
alatt értesíteni lehessen - a mai gyakorlattal ellentétben, 
ahol ez órákat, sőt napokat vehet igénybe. A kiszolgálók közt 
a frissítések olyan gyorsan haladnak, mint az üzenetek. Mi- 
vel az Exchange 2000 csak kis mennyiségű adatot továbbít, 
a frissítések még azelőtt továbbításra kerülhetnek, hogy a 
rendszergazdák érzékelnék a problémát. 


Az üzenetkezelés jövője 

Itt csak néhány dolgot mutattam be az Exchange 2000 új 
technológiáiból. Az adminisztráció és az irányítás szétválasz- 
tásán túl az üzenetkezelő rendszer számos további lehetősé- 
get kínál az SMTP szolgáltatással, és a virtuális kiszolgálók- 
kal kapcsolatban. És ha ez nem lenne elég, a kapcsolatállapot 
alapú irányítás önmaga megérdemelne egy külön cikket. 
Összefoglalva, az Exchange 2000 jelentősen különbözik elő- 
deitől. Mivel az Exchange 2000 csak Win2K rendszereken 
fut, és az első Exchange 2000 kiszolgáló telepítése előtt ti- 
pikusan már komoly infrastruktúra van jelen, az SMTP és az 
Exchange 2000 pontos megismerése komoly időt vehet 
igénybe. Azonban meg kell érteni, hogy az SMTP jelenti az 
egyik legszorosabb kapcsolatot a Win2K és az Exchange 
2000 közt. Az üzenetirányítás jövőjét az Echange kiszolgá- 
lókban az SMTP jelenti. 


Soós Tibor, MCSE, MCT 
soost eigsoft.hu 


Szerzőnk az Exchange Server 4.0 megjelenésétől szakértő- 
je és oktatója az Exchange rendszereknek, az Exchange 
2000 levelezőlista tanácsadója, az IOSOFT - John Bryce 
Oktatóközpont munkatársa. 


A MICROSOFT MAGYARORSZÁG SZAKMAI MAGAZINJA 
2001. 04. 


32 


A 


SZABVÁNYOK 


Mime 


levelezés az interneten 


áá 


33 


Szabványrovatunk most a megszokottól eltérően alakul: a 
téma szerteágazó mivolta (és a rengeteg forrásanyag) miatt 
lapunk oldalain megpróbáljuk összefoglalni az internetes le- 
velezés alapjait képező szabványokat és ajánlásokat, a 
nyolcvanas évek elején megalkotott, spártaian egyszerű RFC 
822-től (, Standard for the Format of ARPA Internet Text Mes- 
sages") egészen a napjainkban divatos, színes, szagos, né- 
ha zenélő HTML levelekig. Hogy kezdődött? Hova jutottunk? 
Mi a baj az ékezetekkel, a kódtáblákkal, a távol-keleti nyelv- 
járásokkal és a HTML levelekkel? 


RFC 822 - Szöveges üzenetek az Interneten 

Az 1982-ben megjelent RFC 822 [1] meghatározta az Inter- 
neten (pardon, akkoriban talán még ARPANet-en) keresztül 
történő szöveges levelezés alapjait. Ez nem más, mint egy 
szöveges adathalmaz formátumának meghatározása, ami 
olyannyira sikerült, hogy a mai napig erre épül az Interne- 
ten küldött legtöbb levél. A levelek továbbítására használt 
SMTP protokoll leírását az RFC 821-ben [2] találja meg az 
olvasó, ennek tartalmára jelen cikk keretein belül nem té- 
rünk ki, de előfordulhat, hogy a cikksorozat elemei között 
találkozunk majd vele is. A protokoll megemlítése itt azért 
fontos, mert a levélformátumhoz hasonlóan az SMTP kom- 
munikációs szabvány is fennmaradt, és ez okozza a mai na- 
pi levelezésünkben felmerülő problémák nagy részét. De ne 
temessük az SMTP-t, egy közel húszéves protokoll nem tehet 
arról, hogy a világ levelezőkiszolgálóinak nagy részéből hiá- 
nyoznak az azóta megjelent fejlesztések... 

Visszatérve az RFC 822 üzenetre, az a következőkből áll össze: 


originator address 
recipient address(es) Message 
mode of delivery envelope 
Header 
Happy birthday! 
See this evening, 
Feci Body 








5 Egy SMTP üzenet felépítése 


A teljes üzenet tehát egy , borítékban" (envelope) foglal he- 
lyet. Ezzel a borítékkal az átlag felhasználó általában nem ta- 
lálkozik, erre ugyanis a levelező kiszolgálók közötti kommuni- 
káció során van szükség. A boríték tartalmát a levelet küldő 
kiszolgáló (vagy levelezőprogram) generálja, általában az üze- 
netbeli információk alapján: értesíti a célkiszolgálót, hogy ki 
a következő üzenet feladója (originator), címzettje (reci- 
pient) , mi legyen a kézbesítés módja, satöbbi. Ez a kommuni- 
káció voltaképpen az SMTP protokoll része. A dolog érdekes- 
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sége az, hogy az eredeti levél fejrészébe írt adatoknak nem 
kell feltétlenül megegyezniük a boríték részben továbbítot- 
takkal, a feldolgozás mégis a boríték adatai alapján megy 
végbe (a címzett például az lesz, akit a borítékban meghatáro- 
zunk, és nem feltétlenül az, aki a levélben szerepel). 

Mint arra már utaltam, ez a boríték a felhasználó elől az esetek 
többségében rejtve marad. Amivel mi, földi halandók találko- 
zunk, dolgozunk, az az ábrán a Message Contents részben látható 
- maga az üzenet. A továbbiak során csak ennek a résznek a vizsgá- 
latával foglalkozunk, a többi az SMTP protokoll (RFC 821) feladata. 
Az üzenet két részből áll, ezek a fejlécek (Header) és az üzenet 
törzse (Body). Egy nagyon egyszerű levél valahogy így néz ki: 


From: benotnetacademia.net 
To: jenotgnetacademia.net 


Subject: Ez egy egyszeru level 
Ez a level torzse. 


Mindenekelőtt fontos megjegyezni, hogy a szabvány szerint a 
teljes kommunikáció ember által olvasható formában, mégpe- 
dig szigorúan a 7 bites ASCII karakterkészlet elemeit használ- 
va zajlik. (Ha ettől el akarunk térni, az üzenet tartalmát kódol- 
ni kell, de erről majd később.) Az üzenet fejrészét és törzsét 
egy üres sor választja el, ami a sorvégjelként használt 
wCRLF:" karakterpárok segítségével kifejezve ,,-CRLF2-CRLF5", 
Minden, ami e karaktersorozat előtt szerepel, fejlécnek tekin- 
tendő, és természetesen minden, ami ezután található az üze- 
netben, az maga az üzenet törzse. Az elválasztó üres sor nem 
tartozik az üzenethez. A törzs megadása nem kötelező, ekkor 
jutunk el az ,üres üzenet" definíciójához :-) 


Fejlécmezők 

Az üzenet fejrésze egy vagy több mezőt (fejlécet) tartalmaz 
(a fenti példa például rögtön hármat). Egy fejléc a következő- 
képpen épül fel: 


fejléc-név:fejléc-törzscCRLF5 


Egy fejléctörzs átlóghat a következő sorba, mégpedig úgy, 
hogy a törzsrészben található úgynevezett , whitespace" ka- 
rakterek (például a tabulátor és szóköz) elé sorvégjelet 
(cCRLF2) szúrunk. Ilyenkor a következő sor természetesen a 
whitespace karakterrel kezdődik, ebből lehet tudni, hogy az 
nem egy új fejlécmező nevének kezdete, hanem az előző me- 
ző törzsének folytatása. Például: 


From: benofnetacademia.net 

To: jenognetacademia.net 

Subject: Ez egy tobb sorban 
elkuldott fejresz, ami 


megis egy sorban jelenik meg majd. 
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A fejléc csak ASCII karaktereket tartalmazhat, azok közül is 
csak a nyomtatható fajtákat (plusz természetesen a whitespace 
karakterek: szóköz, tabulátor, sorvégjel). A mezők neve és tör- 
zse értelemszerű okokból nem tartalmazhatja a kettőspontot. 
Az RFC 822-ben definiált és ajánlott fontosabb mezők: 

"B From: Az üzenet feladója 

"0 Sender: Az a személy, program, vagy szolgáltatás, 
aki/ami az üzenetet elküldte 

Reply-to: Az a cím, ahova a válaszüzeneteket várjuk 
(nem feltétlenül egyezik meg a feladó címével) 

To: Az üzenet címzettje(i) (elsődleges címzettek) 

Cc: Másolatot kapnak (másodlagos címzettek) 

Bcc: ,Vakmásolatot" (Blind Carbon Copy) kapnak. Az itt 
felsorolt címek nem szerepelnek az üzenetben (csak a 
borítékban) , tehát az üzenet többi címzettje nem szerez 
tudomást róluk (és ők egymásról sem). 

Ezen kívül léteznek további, üzenetkezeléshez használatos 
mezők (Message-ID, References, Keywords) , dátum és időazo- 
nosítók (Date), és természetesen az üzenet témája (Sub- 
ject), valamint a fejrészben szerepelhet bármilyen, felhasz- 
náló által definiált mező (X-....... ). A mezők sorrendje 
egyébként nem kötött. 


p 


B 


5 


Érdekesség, hogy a USENET hírcsoportok alapját is az 
SMTP levelek képezik. A legfontosabb különbség az, 
hogy ilyenkor a címzett To: mező helyett Newsgroups: 
szerepel, de az üzenetek formátuma teljesen megegye- 
zik a hagyományos levelekkel. 


Dátum 
A dátummezőben használt időformátum az alábbi: 


Thu, 15 Mar 2001 17:53:27 —0800 


A nap angol megnevezése (és az azt követő vessző) elhagyha- 
tó, azután következik a nap (egy vagy két karakteren), majd a 
hónap rövid angol neve, az év (a szabvány szerint még kettő, 
Y2K óta természetesen négy karakteren) , az óra, perc és másod- 
perc két-két karakteren, kettősponttal elválasztva (a másod- 
perc elhagyható) , végül az időzóna. Az időzóna lehet a Green- 
wich-i középidőtől való eltérés --/-óópp formátumban, valame- 
lyik általános zónarövidítés (pl. GMT, ÚT, EST, CST, stb. ), illet- 
ve érdekes módon amerikai katonai meghatározás (pl. A-Z). 


A címzés formátuma 

A fejlécmezők többsége természetesen e-mail címeket tartal- 
maz. A legegyszerűbb mód természetesen, ha csak az e-ma- 
il címet adjuk meg: 


To: benotnetacademia.net 

De a címekhez általában tartozik valamilyen becsületes név 
is, ilyenkor a nevet idézőjelbe tesszük, az e-mail címet pe- 
dig kacsacsőrök közé zárjuk: 

To: "Fu Beno" cbenotnetacademia.net: 

A felhasználó , barát" levelezőprogramokban ilyenkor csak a 


sszép név" jelenik meg. 
Több címet úgy adhatunk meg, ha a fenti formátumban el- 
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készített címeket egymás után vesszővel elválasztjuk. Ter- 
mészetesen ilyenkor is használhatjuk a mezők több sorba 
tördelését (ezt egyébként a szabvány , folding"-nak hívja): 


To: "Fu Beno" cbenognetacademia.net2, 
"Fenyo Jeno" cjenotnetacademia.neto, 


Telapotfunet.fi 


Ennyi? 

Bizony, körülbelül ennyi. Habár nem tértünk ki arra, hogy 
milyen fejléc-mezőket definiáltak például az üzenetek továb- 
bításához, visszaküldéséhez, az RFC-822 legfontosabb ré- 
szeit megismertük. A levelezés akkor még kizárólag ASCII 
szöveges üzenetek továbbításáról szólt, szó sem volt alter- 
natív tartalomról, karakterkészletekről, csatolt fájlokról. 


UUEncode/UUDecode 

Miután a felhasználók kezdtek rászokni a hálózaton keresztüli 
levelezésre, egyre nagyobb volt az igény arra, hogy a szöveges le- 
velekbe szövegen kívül mást is tölthessenek. Az egyik legelső ilyen 
metódus a UUEncode (Unix-to-Unix Encode) volt, amit a USENET 
hírcsatornákon egyébként a mai napig gyakran használnak. 
Az üzenetek formátuma nem változott: a csatolt állományo- 
kat az üzenetek törzsébe, annak is a végéhez csatolják, egy 
speciális fejléc után. A kódolás során a bináris adatot vala- 
hogyan az üzenet törzsébe tuszkolják úgy, hogy csak szab- 
ványos, 7 bites ASCII karaktereket használnak. A trükk: az 
üzenet minden 3 bájtját négy hatbites darabra bontanak, 
majd az így kapott értékekhez hozzáadnak 32-t. A bájtok ér- 
téke 32 (szóköz) és 32--((25-1)-95 (alulvonás) közé kerül, és 
könnyen beilleszthető az üzenetbe (cserébe a csatolt állo- 
mány mérete megnő, mégpedig 4/3-ára.) 


From: "Zxxxxx" Czxxxxxébikerider.com 
Newsgroups: alt.binaries.pictures.motorcyc 
Subject: Re: Yamaha de MX roja y blanca 
Lines: 1153 

Date: Thu, 15 Mar 2001 O8:09:33 GMT 


Parece un salto de la htstia, pero es porgue la 
calle está más baja gue el circuito, de ahí la 


altura de las farolas :-) 


vs 


Xavi 


begin 666 yz125.jpa 
"02D9)1871"0$7EG"677$ VPLHT, A," 0,HP,$"P,$!008 
MIOH"!PB(H H,§ Lr"PL-HA(OHOXLHELH$!BOSI,431458 (78 
U-:d 

:ABHOASÉZ6GD" "5U, CEL/ERSOILPAOFN,0£5K$ : 2E( IZXAZAN§ ! 0 
1"NPO:JKVEPP?OLYSÁL JD 


end 


Fülöp Miklós 

[mickonetacademia.net] 
[1] http://www.ietf.org/rfc/rfcO822.txt 
[2] http://www.ietf.org/rfc/rfcO821.txt 
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JOGI ESETEK 


Most, amikor Magyarországon az Országgyűlés már tárgyalja 
az elektronikus kereskedelemről szóló törvény tervezetét, és 
az előzetes információk szerint májusban várható a törvény 
elfogadása, talán nem szükségtelen, hogy a magyar jogalko- 
tásra kétségtelenül legnagyobb befolyást gyakorló, és a jog- 
harmonizációs kötelezettségek miatt a kereteket meghatá- 
rozó szabályozást, az Európai Unióban e tárgyban megszüle- 
tett irányelvet részletesebben megvizsgáljuk. 

A szabályozás irányelv formájában jelent meg, amelyet az 
1998.-as első tervezetet követően az EU döntéshozatal-előké- 
szítési folyamatának számos lépcsőjét megjárva, néhány mó- 
dosítás után 2000. június 8-án fogadtak el. Az irányelv, mint 
jogforrás a tagállamokra további kötelezettséget ró, annak ke- 
retei között a meghatározott határidőn belül meg kell alkotni 
a nemzeti jogszabályt. Így tehát az EU tagállamokban lázas 
munka kezdődött az e-commerce törvényi szabályozására. 

Az elektronikus kereskedelemről szóló irányelv kizárólag az 
internal market , az Uniós belső piac jogi viszonyainak ren- 
dezésére vállalkozik, külső (external) vonatkozásokkal nem 
foglalkozik. A nem uniós országokban működő szolgáltató- 
kat tehát azok a lehetőségek, amelyeket az Irányelv kínál, 
nem illetik meg, s ha erre mégis igényt tartanak, akkor va- 
lamely uniós országban regisztráltatni kell magukat. 

A szabályozást öt lényeges kérdés köré csoportosították: 
Az információs társadalomban a szolgáltatói szféra megala- 
pozása (establishment of service providers). Az Irányelv cél- 


ja, hogy e téren a jogi bizonytalanságot eloszlassa. Két 
alapelvet mond ki e körben: a service provider-jellegű szol- 
gáltatást nem lehet különleges engedélyezéshez kötni, 
ugyanakkor az SP köteles magáról - pontosan meghatáro- 
zott, azonosításához szükséges - adatokat közölni. 

A kereskedelmi kommunikáció (reklám, direkt marketing 
stb.) Az alapgondolatok: a kommunikáció megbízhatósága 
(a visszaélések veszélyének csökkentése, felhasználó-fogyasz- 
tóvédelem) , valamint az egyes különleges hivatások (jogász, 
orvos) sajátos - s a szakmai etikával összeegyeztethető - 
reklámjának megengedése. 

Az online szerződéskötés joghatályának elismerése. Az alapelv e 
körben: a szerződéskötési szabadság érvényre juttatása mellett a 
kormányoknak olyan jogi környezetet kell teremteni, mely az 
elektronikus szerződéskötés feltételeit és joghatályát biztosítja. 
A közreműködők felelősségi kérdéseinek rendezése. Az 
alapelv: egyrészt a felelősségi rendszer (felelősségi lánc) 
felépítése, másrészt ezen belül az ISP felelősségének korlá- 
tozása a közreműködők, azaz szolgáltatást igénybe véve 
szolgáltatók cselekedeteiért. 

Végrehajtás. E körben a tagállamok felé alapkövetelményként 
fogalmazza meg az Irányelv az online környezet gyors, haté- 
kony jogi rendezésében való közreműködést, úgy a nemzetközi 
szabályozási munkában, mint a nemzeti szintű jogalkotásban. 
Az Irányelv a szankciók megállapítását a nemzeti jogalko- 
tásra bízta azzal a kritériummal, hogy a szankcióknak haté- 


A MICROSOFT MAGYARORSZÁG SZAKMAI MAGAZINJA 
2001. 04. 


Elektronikus 


kereskedelem 


konynak, arányosnak és visszatartónak kell lennie. 

Nem tartoznak az Irányelv hatálya alá az adózási kérdések, a 
95/46/EC és a 97/66/EC Irányelvekben meghatározott infor- 
mációs társadalmi szolgáltatásokkal kapcsolatos kérdések, a 
kartelljog által szabályozott területek, az információs társadal- 
mi szolgáltatások közül a közjegyzők, vagy velük azonosnak 
minősülő szakmák, amelyek közvetlen és speciális kapcsolatot 
igényelnek, és közhatalmat gyakorolnak, az ügyfél vagy vé- 
denc képviselete a bíróság előtt, és a szerencsejátékok. 

Az Irányelv az elektronikus kereskedelem tárgya és sze- 
replői szempontjából az alábbi fogalmak meghatározását 
tartotta fontosnak. 


Információs társadalmi szolgáltatás 

Minden olyan szolgáltatást ide sorol, amelyet általában dí- 
jazás ellenében, távolról, elektronikus úton és a szolgáltatás 
címzettje egyéni kérésére nyújtanak. Ide tartozik tehát bár- 
milyen B2B vagy B2C viszonylatban általában ellenszolgál- 
tatás fejében, de kivételesen ingyenesen is (olyan honlap 
estében, amelyre a látogató az Internet-hozzáférésért fizeten- 
dő díjtól eltekintve ingyen vehet igénybe, a szolgáltatást a 
beépített reklámok tartják el) nyújtott szolgáltatás: pl. Inter- 
net-hozzáférés biztosítása, weboldal fenntartása (tárhely- 
biztosítás), Bulletin Board Service (BBS, elektronikus faliúj- 
ság) fenntartás, e-mail szolgáltatás, kereső- és portálszolgál- 
tatás, online termékértékesítés, más online szolgáltatások 
(pl. pénzügyi) nyújtása, online kiadó (újság), online kulturá- 
lis szolgáltatás, különösen szerzői művek felhasználása (lehí- 
vása letöltési lehetőséggel vagy anélkül). Lényeges tartalmi 
elem, hogy a szolgáltatás nyújtása telekommunikációs esz- 
köz útján, elektronikus úton történjen a szolgáltatást igény- 
be vevő írásbeli vagy ráutaló magatartással kifejezett (rák- 
kattintás - click on) megrendelése alapján. A felek távol van- 
nak, azaz nincsenek együttesen, adott helyszínen jelen a 
szerződés megkötésekor. A szolgáltatásnak minden esetben 
egyedileg igényeltnek kell lennie, olyannak, amit adatok 
egyéni kérésre történő sugárzásán keresztül nyújtanak. 


Szolgáltató 

Minden olyan természetes, vagy jogi személy, amely infor- 
mációs társadalmi szolgáltatást nyújt. E tekintetben szolgál- 
tató az access provider (a hálózati távközlési hozzáférést biz- 
tosító szolgáltató pl. Matáv, Westel, stb.), a Service Provider 
(a szűk értelemben vett Internetszolgáltató, aki a szerverén 
adattárolást, honlap-fenntartást, a hálózaton adattovábbítást 
és egyéb szolgáltatást is nyújtó szolgáltató), a content pro- 
vider tartalomszolgáltató, akinek honlapja útján az Internet 
felhasználói, e viszonylatban fogyasztók a tartalomszolgál- 
tatónak az előbbiekben említett szolgáltatók közreműködé- 
sével nyújtott szolgáltatásait elektronikus kommunikáció 
útján igénybe veszik, valamint az Internetszolgáltató és tar- 
talomszolgáltató együttes szerepét ellátó online szolgálta- 
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tó, aki a tartalomszolgáltatás mellett tárhelyet is biztosít, 
pl. BBS elektronikus faliújság útján. 

Megalakult szolgáltatónak nevezi az Irányelv az olyan szol- 
gáltatót, aki a gyakorlatban gazdasági tevékenységet vé- 
gez, állandó telephelyet használva határozatlan időre. A 
szolgáltatás nyújtásához szükséges műszaki eszközök és 
technológiák jelenléte és használata nem jelenti azt, hogy 
a szolgáltató megalakult. 

Az információs társadalmi szolgáltatóvá válást nem lehet elő- 
zetes engedélyezéshez, vagy bármilyen más olyan aktushoz 
köti, mely hatósági hozzájárulás formájában nyilvánul meg. 
Ez azonban magához az ISP-jelleghez kötődő különleges en- 
gedélyekre vonatkozik csak, egyébként az általános kereske- 
delmi szereplővé válási feltételeknek meg kell felelniük. 

A szolgáltató - minden szolgáltató - köteles magáról szé- 
les körben információt nyújtani. Neve, működése szerinti 
székhelye, kapcsolattartás a szolgáltatóval e-mail formá- 
ban, hol, mely kereskedelmi nyilvántartásban regisztrálták, 
mi a regisztrációs száma, engedélyhez kötött tevékenység 
esetén az engedély száma, annak a szakmai szervezetnek 
megnevezése, melyhez - ha az országban van ilyen - a 
szolgáltató tartozik, s végül - ha a tevékenység forgalmi 
adó köteles, az ország saját szabályai szerinti adóazonosí- 
tó vagy adószám megadása. 

A kereskedelmi szolgáltatókkal szemben az Irányelv több- 
letkövetelményeket állít. Első a ,tisztán azonosíthatóság", 
második a felelős személy megnevezése, harmadik a promó- 
ciós-reklámjellegű anyagok (akciók, ajándékok stb.) sajátos 
megjelölése, a negyedik a kereskedelmi vetélkedők és játé- 
kok engedélyhez kötési lehetőségének elismerése mellett az 
ilyen akciók egyértelműségének, tisztességének biztosítása. 


A szolgáltatás címzettje 

Minden olyan természetes, vagy jogi személy, aki szakmai 
célból, vagy más okból információs társadalmi szolgáltatást 
vesz igénybe, különösen azért, hogy információhoz jusson, 
vagy azt elérhetővé tegye. 


Fogyasztó 

Fogyasztó alatt a már hagyományosan elfogadott fogalom- 
mal találkozhatunk ismét: bármely olyan természetes sze- 
mély, aki a saját üzleti, kereskedelmi vagy szakmai tevé- 
kenysége körén kívül eső cél érdekében cselekszik. 

Az Irányelvben önálló alfejezetet kapott a kereskedelmi 
kommunikáció (Commercial Communication) . Ez három kör- 
ből áll: a szolgáltatók által nyújtott többletkövetelmények, 
a nem kívánt kereskedelmi e-mail kérdése, s egyes, külön 
szabályozás alá eső hivatások reklámozásának kérdése. 
Kereskedelmi közleménynek minősül a közlés bármilyen 
formája, ami árucikkeknek, szolgáltatásoknak, továbbá 
cég, szervezet, illetve kereskedelmi, ipari, vagy kézműves 
tevékenységet folytató, illetve szabadfoglalkozású személy 
gál. Nem minősülnek kereskedelmi közleménynek egy vál- 
lalat, szervezet, vagy személy tevékenységéhez való köz- 
vetlen hozzáférést lehetővé tevő információk, így különö- 
sen domain név, vagy e-mail cím továbbá az árucikkekre, 
szolgáltatásokra, vagy cég, szervezet, illetve személy arcu- 
latára vonatkozó, függetlenül, így különösen nem anyagi 
megfontolásból összeállított közlemény. 
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A kereskedelmi közlemények kötelező tartalmi elemei a kö- 
vetkezők: 

5 a kereskedelmi közlemény legyen egyértelműen 
azonosítható 

-£ egyértelműen legyen azonosítható az a természetes, 
vagy jogi személy, akinek érdekében a kereskedelmi 
közleményt megalkották 
a promóciós ajánlatok, például kedvezmények, jutal- 
mak és ajándékok (amennyiben engedélyezettek) , egyér- 
telműen azonosíthatók legyenek, az azok igénybevéte- 
léhez előírt feltételek pedig könnyen hozzáférhetően, 
pontosan és egyértelműen legyenek feltüntetve 
a promóciós versenyek, vagy játékok (amennyiben en- 
gedélyezettek), egyértelműen azonosíthatók legyenek, 
és a részvételhez előírt feltételek könnyen hozzáférhe- 
tően, pontosan és egyértelműen legyenek feltüntetve. 
Külön foglalkozik az Irányelv a nem igényelt kereskedelmi 
közlemények (spam) kérdésével is. E tekintetben a tagálla- 
mokra bízza annak szabályozását, hogy a nem igényelt, e- 
mailen terjesztett kereskedelmi közleménynek világosan, és 
egyértelműen azonosíthatónak kell lennie a címzett általi 
átvétel időpontjában. A spam körében új rendelkezés az opt- 
out nyilvántartások felállításának igen határozott támogatá- 
sa: a természetes személyek számára biztosítani kell a jogot, 
hogy e nyilvántartásba felvételt nyerhessenek, s így a nem 
kívánt kereskedelmi kommunikáció ellen védekezhessenek. 

Az alkalmazandó jogként az Irányelv annak az országnak a jogát 

tartja irányadónak, ahol a szolgáltatást nyújtó székhelye van. 

A Section 3. az elektronikus szerződésekről rendelkezik. Itt 

is rögzíti az Irányelv, melyek a kötelező elemek, s milyen 

feltételek mellett lehet a szerződési folyamatot biztosítani. 

Négy körben jelöli meg azokat a kivételeket, mikor nem le- 

het elektronikus szerződési formát választani: 

"5 minden olyan szerződés, mely ingatlanra vonatkozó jog 
átszállásával kapcsolatos (kivéve a bérleti jogot) 

-£ olyan szerződések, melyeknek érvényességéhez vala- 
mely közhitelű nyilvántartásban való regisztráció 
szükséges 

2 kezesség, jótállás, garancianyújtás olyan esetben, ha a 
cél az adott személy üzleti, kereskedelmi vagy szak- 
mai körén kívül esik 

-2 a családjog és az öröklési jog körébe tartozó szerződések 

Az Irányelv azt is előírja, hogy a szolgáltatónak az elektroni- 

kus szerződéskötési folyamatban milyen tájékoztatási, adat- 

rögzítési, és hozzáférés-biztosítási kötelezettségei vannak. 

Az egyik legvitatottabb kérdést, a szerződés létrejöttének 

időpontját az Irányelv akként rendezi, hogy nem elegendő 

a szerződés létrejöttéhez az egyszerű klikkelés, hanem 

szükséges a szolgáltatótól való visszajelzés a megrendelés 

átvételének elismeréséről, továbbá a megrendelőtől annak 
visszaigazolása, hogy az elismervényt megkapta. E körben 
két további elvet kell alkalmazni: a rendelést akkor lehet 
elfogadottnak mikor, a szolgáltatás igénybe vevője ahhoz 
hozzá tud férni. Ugyanakkor a szolgáltatónak kötelezettsé- 
ge a rendelés visszaigazolásának haladéktalan elküldése. 

További előírás, hogy a szolgáltatónak a szerződési- és ál- 

talános feltételeket úgy kell hozzáférhetővé tenni, hogy a 

vevő ezt rögzíteni (menteni) és reprodukálni tudja. 

A másik legtöbb vitát kiváltó kérdés: a Service Provider (Inter- 

netszolgáltató) felelőssége. Az Irányelv a közreműködő Inter- 
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netszolgáltató felelősségét korlátozza, és a szolgáltatói felelős- 
séget kizárja azokban az esetekben, mikor nem ő kezdeményez- 
te az adatátvitelt, nem ő választotta meg az adatátvitel cím- 
zettjét, s nem ő határozta meg az adatátvitel tartalmát. 

A caching-ért, és a hosting-ért való szolgáltatói felelősség 
kizárásának feltételeit is az ISP előbb vázolt felelősségéhez 
hasonlóan rendezi az Irányelv. A szolgáltatók szempontjából 
lényeges annak kimondása, hogy nem terheli őket kötele- 
zettség az általuk továbbított vagy tárolt információ figye- 
lésére, nincs tehát monitoring-kényszer, ez azonban nem 
érinti a hatóságok törvényi felhatalmazás alapján történő 
hasonló törekvéseinek semminemű korlátozását. 

Az irányelv a viták rendezését lehetőleg a bíróságokon kívü- 
li fórumok kezébe kívánja helyezni hasonlóan a fogyasztó- 
védelem területén mutatkozó megoldásokhoz. Optimálisabb 
megoldást jelenthetne a mindenhol igen lassan működő 
igazságszolgáltatással szemben a gyors, hatékony, egy-, 
legfeljebb kétfokú, hozzáértőkből álló vitarendezési fórumok 
felállítása, és az Internettel kapcsolatos vitáknak itt törté- 
nő rendezése. Az Internet nem tűri a lassú döntéseket: mi- 
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re a bírósági határozat megszületik, a peres felek érdekei 
már régen meghaladottakká válnak. A speciális technikai 
háttér megfelelő szintű ismerete is szükségessé válhat a jog- 
vita alapos megismeréséhez és eldöntéséhez. A domain ne- 
vekkel kapcsolatos vitarendezési eljárások (WIPO illetve a 
magyar megoldás Tanácsadó Testület illetve eseti választott- 
bíróság) már bizonyítottak, működnek. Az elektronikus ke- 
reskedelemmel kapcsolatos viták területén is minden bi- 
zonnyal hatékony alternatívája lehet a hagyományos bírói 
útnak egy másik fórum. 


Dr. Mayer Erika 

Nádas 8. Mayer Ügyvédi Iroda 

1137 Budapest, Radnóti Miklós u. 38. 
Tel: 340-4150, 06-309-318-089 
E-mail: mayer(onadas-mayer.hu 


64 és 128 Kbít/sec-os 
Berelt vonalak 


vbelépési díj nélkül 
vrouter biztosításával 
vwebszerver működtetésével 


v ajándék telefonos interneteléréssel 
v1 db .hu és 1 db .com domainnév regisztrációj 


YVDNS szerviz biztosítással 


3 Az áraink ÁFA nélkül és 2001. április 30-ig érvényesek. 
Érdeklődjön a 06-40-HUNNET telefonszámon vagy info(-odahol.com címen! 
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ASP suli 
(IV. rész) 


A kis nyelvészkedési kirándulás után hamarosan visszatérünk az 
ASP programozáshoz. E számunkban bemutatjuk az Application és 
Server objektumokat, ennek kapcsán kitérünk az ASP alkalmazások 
mibenlétére is, végül egy újabb naplózási trükk következik majd. 
Mint mindig, a példaprogramok megtalálhatók az [1] címen. 


Az ASP alkalmazás 

Mint arra már néhány héttel ezelőtt kitértünk, az ASP alkalma- 
zás egy adott virtuális könyvtárban (és annak gyermekkönyvtá- 
raiban) elhelyezett ASP fájlok gyűjteménye, valamint természe- 
tesen az azokat körülvevő keretrendszer. Az IIS már telepítése- 
kor létrehozza a teljes webet magába foglaló alapértelmezett 
ASP alkalmazást, a , Default Application"-t. Nyissuk meg a De- 
fault Web Site tulajdonságlapját, és kattintsunk a Home Direc- 
tory (alsóbb könyvtárszinteken csak ,, Directory") oldalra: 





Default Web Site Properties 2]2d 


Directory Security]  HTTPHeaders ]  CustomErors ]  ServerExtensions ] 
WwebSite ] Performance ] ISAPIFiters — HomeDirectoy ] Document ] 
"When connecting to this resource, the content should come from: 

G A dírectoty located on this computer 

C A share located on another computer 

C A redirection to a URL 








Local Path: w.Ninetpubtwwwroot Browse... 
I Script source access [7 Log visits 
7 Read [7 Index this resource 
TT wiite 
TT Directory browsing 
Application Settings 
Application name: Default Application Remove 
Starting point: Default Web Site 
Configuration.... 
Execute Permissions:  [Scipts ony . 
Application Protection: . [Medium (Pooled) s Unload 

















Cancel épply Help 


a Az alapértelmezett webalkalmazás beállításai (az ablak 
alsó felében láthatók) 


Az Application Settings választóvonal alatt található elemek 
mind-mind az ASP alkalmazás kezelésére szolgálnak. Minde- 
nekelőtt láthatjuk az alkalmazás nevét, a kezdőpontját (gyökér- 
könyvtárát, esetünkben ez maga a virtuális web) , valamint a scrip- 
tek futtatására és az alkalmazás védelmére vonatkozó ablakokat. 
Mielőtt ezek értelmezésébe belemennénk, lássuk a gombokat: a 
Remove eltávolítja, megszünteti a webalkalmazást (a lemezen ta- 
lálható fájlok ettől nem sérülnek meg). Bár a gyökéralkalmazás is 
megszüntethető, ennek véghezvitele csinos kis hibaüzenetekhez 
vezet mind a böngészőben, mind a kiszolgáló eseménynaplójá- 
ban. A hierarchia alsóbb szintjein található alkalmazásokat vi- 
szont különösebb probléma nélkül megszüntethetjük. 

Az Unload gomb megnyomására a webalkalmazás kitöltődik, tá- 
vozik a memóriából. Törlődnek az ASP objektumok adatai, fel- 
szabadulnak az IIS által fogott DLL-ek, és a legközelebbi alka- 
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lommal ismét lefutnak a definiált inicializáló rutinok. A Configura- 
tion gomb megnyomására megjelenő párbeszédablak már ismerős 
lehet, és még lesz is szó róla: ebben lehet meghatározni az egyes 
kiterjesztésű fájlokat kezelő rendszerkomponenseket, a hibakere- 
sés (ASP debugging) beállításait, valamint az alkalmazás globális 
paramétereit (alapértelmezett scriptnyelv, időtúllépés, stb.) 











Application Settings 


Application name: 


Default Application Remove 
Default Web Site; 


Unload 





Starting point: 
Execute Permissions: 












Application Protection: [g 





0 A választható futtatási jogosultságok 


A futtatási jogosultságok 

Az , Execute Permissions" mezőben három lehetőség közül vá- 

laszthatunk: 

"0 None: Csak statikus működés engedélyezett. Scriptek és 
programok nem futtathatók. Ezt használjuk akkor, ha nem 
használunk aktív komponenseket 

"0 Scripts only: Scriptfájlok végrehajtása engedélyezett, de 
különálló programok továbbra sem futtathatók. Ez az alap- 
értelmezett és ajánlott beállítás 

"0 Scripts and Executables: A legveszélyesebb, CGI-kompatibi- 
litás miatt megtartott opció. Ilyenkor a scriptek mellett a 
könyvtárakban található programok is lefuthatnak. 


Az alkalmazás védelme 

A meghatározás tulajdonképpen hibás, ugyanis nem a webalkal- 
mazásunkat, hanem magát az IIS-t védjük a saját csínytevé- 
seinktől (na jó, esetleg magunkat a többi webalkalmazástól) . 
Hogy miért kell ez a védekezés? 

A webalkalmazások saját útjaikat járják. Az esetek többségében 
(például .díl fájlokban megírt) külső komponenseket használnak, 
hibátlan program pedig, mint tudjuk, nincsen. A .dll-ek közis- 
mert tulajdonsága, hogy a szülőprocessz címtartományába töl- 
tődnek be, és ha a .dil készül elhalálozni, a szülőprocesszt is ma- 
gával rántja. Így lehet egyetlen .dil segítségével a nullával 
egyenlővé tenni a webkiszolgálót. 

Pontosan az ilyen esetek elkerülésére találták ki az , alkalmazások 
védelme" (, Application Protection") opciót. Egy (.dll-eket töltöge- 
tő) webalkalmazás (kvázi maga a .dil) három módon töltődhet be: 
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5 A webalkalmazás három védelmi szintje 
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8 (Low): az IIS processzbe. Ez gyors, de veszélyes működést 
eredményez, hiszen ha a .dil kipukkan, megy vele az IIS is. 

8 (Medium - Pooled): egy, az IIS processzétől elválasztva fu- 
tó processzbe. A processz neve dilhost.exe, megleshetjük a 
Task Managerben. Minden Medium szintű webalkalmazást 
ugyanaz a dllhost.exe futtat, tehát ha a több Medium szin- 
tű alkalmazásból egy elhasal, magával rántja a többit is - 
az IIS viszont talpon marad. Ez az alapértelmezés, mert vi- 
szonylag biztonságos, és nem igényel sok erőforrást. 

"0 (High - Isolated) A High szintre helyezett webalkalmazások 
mindegyike saját dllhost.exe-t kap, amibe annyira és 
annyiszor rúghat bele, ahányszor csak akar, önmagán kívül 
senkinek sem árthat vele. Akit érdekel, kipróbálhatja: nyis- 
son meg egy Task Manager-t, állítsa a futó processzeket 
név szerint sorba, és meglátja, hogy n darab dllhost.exe 
fut. Majd állítson egy webalkalmazást High szintre, és nyis- 
son meg egy oldalt belőle: a futó dllhost.exe-k száma n--1- 
re nő (az Unload hatására pedig értelemszerűen eggyel 
csökken). Ez a legbiztonságosabb megoldás, de a gyakori 
kontextusváltás miatt sok erőforrást igényel, ezért a Micro- 
soft nem ajánlja, hogy egy kiszolgálóra 2-3-nál több ilyen 
szintű alkalmazás kerüljön. 


Saját webalkalmazás létrehozása 

Saját webalkalmazást úgy hozhatunk létre, hogy egy szimpati- 
kus könyvtár tulajdonságlapján megnyomjuk a Create... gom- 
bot. Ekkor ez a könyvtár lesz az újonnan létrehozott webalkal- 
mazásunk gyökérkönyvtára, aminek különleges jelentősége van: 
azok az ASP fájlok osztanak meg ugyanis közös ASP objektumo- 
kat (például az Application objektumot) , amelyek ugyanabban a 
webalkalmazásban találhatók. 
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£ Gy aspt Directory ] Document: [ Directoy Security ] HTTP Headers ] Custom Enors ] 
a epp "When connecting to this resource, the content should come Írom: 
601 G The designated dírectoty 
501 e 
A ni A share located on another computer 
BO uz C A redíection to a URL 
60 113 
HO u Local Path: Naspátapptzi22 TERT 
a 12 I Sciipt source access [7 Log visits 
a 13 7 Read ÍV Index this resource 
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as Execute Permissions: . [da si] 
az Sile xipts only 
TETT 17 Appteztáon Protection [MeőimíPodegg 7] ÉS 
5 Webalkalmazások hierarchiája 
A fenti ábrán látható hierarchiában most figyeljük az app és a 2 
könyvtárakat (ezek webalkalmazások). Ha megnyitjuk a hierar- 
chiában alattuk található könyvtárak tulajdonságlapjait, láthat- 
juk, hogy melyik webalkalmazáshoz tartoznak: 22 nevű alkönyv- 
tár például a 2-höz, míg a 112 az app-hoz, azaz mindegyik ahhoz 
legközelebbi őséhez, ami webalkalmazás gyökereként funkcionál. 
Az Application objektum 
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Az Application objektum tehát nem más, mint egy közös táro- 
lóhely, amit az adott webalkalmazás minden scriptje elér. Az 
Application objektumban adatokat, objektumokat tárolhatunk 
el, hogy majd később kiolvassuk onnan (csakúgy, mint a Sessi- 
on objektumnál): 


Application("counter") 5 12 
Set Application("myObject") - oMyObject 
Set oMyObject2 - Application("myObject") 


Amint az a fenti példában is látható, az Application objektum- 
ban is tárolhatunk más objektumokat. Nem szabad elfelejtkezni 
azonban két nagyon fontos dologról: 

8 Az objektumokat Set értékadás segítségével kell az Applica- 
tion objektumba betölteni, és a kiolvasásuk is a Set parancs 
segítségével történik. 

8 Nem minden objektum alkalmas arra, hogy az Application 
objektumba töltsük! Az IIS ugyanis többszálú alkalmazás, 
egyidőben több felhasználót szolgál ki. Az Application ob- 
jektumba csak olyan objektumokat tölthetünk be, amelyek 
többszálú (FreeThreaded) végrehajtási módban képesek mű- 
ködni és úgynevezett Both threading-modellt alkalmaznak. 
Lásd még: [2] 

Az alábbi példa az Application objektumot használja egy primi- 

tív számláló létrehozásához 


ez 
Application.Lock 
Application("count") z Application("count") $1 
Application.Unlock 


Response.Write("Üdv! Te vagy az IIS újraindítása 
B óta a(z) " 
HW  látogató.") 
45 


§ Application("counter") § 


A példa a valóságban azért használhatatlan, mert a webalkalma- 
zás újraindulásának pillanatában - reboot vagy unload esetén —- 
az Application objektum tartalma, ezzel pedig a számláló érté- 
ke is elveszik. De nem is ez a célunk vele, hanem a demonstrá- 
ció. Az első és a harmadik sorban látható Application.Lock() és 
Application.Unlock() metódus használatára azért van szükség, 
mert az Application globális objektum, és előfordulhat, hogy 
egyszerre több felhasználó szeretné írni ugyanazokat az adato- 
kat. Az ütközések elkerülése végett minden írásművelet előtt az 
objektumot zárolni kell, majd a lehető legrövidebb időn belül az 
Unlock() metódus segítségével fel kell oldani, ugyanis míg az 
Application objektum zárolva van, senki más nem férhet hozzá, 
mint az, aki eredetileg zárolta azt. 


Próbáljuk ki! A lock1.asp zárolja és néhány másodpercig 
zárolva tartja az Application objektumot. Ha a lock1.asp 
futásának ideje alatt megnyitjuk a lock2.asp oldalt, az 
csak a lock1.asp futásának befejezése után lesz képes 
hozzáférni az Application objektumhoz. 


Ha mi nem oldanánk fel a zárolást, az IIS az oldal végrehaj- 
tása után, de legkésőbb a scriptfuttatás időtúllépésekor fel- 
szabadítja azt. 

Természetesen az Application objektum tartalmát is elérhetjük 
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kollekciókon keresztül, erre szolgál az Application.Contents 
kollekció (contents.asp): 


For Each oltem In Application.Contents 
Response.Write(Application(" § oltem £ ") — " a 

B Application(oltem) § "cbr2" ) 

Next 


Ebből a kollekcióból is pontosan ugyanúgy lehet törölni eleme- 
ket, mint a Session-nál is láttuk: 


Application.Contents.Remove ( "counter" ) 
Application.Contents.Remove(2) 
Application.Contents.RemoveAll() 


Az első sor a "counter" értékét, a második sor az Application 
objektumon belüli második változót, míg a legutolsó sor az 
Application objektum teljes tartalmát törölte. 

Az Application.StaticObjects kollekció a global.asa fájlban az 
OBJECT: elem segítségével, , Application" scope-ban létreho- 
zott változókat tartalmazza. A kollekció pontosan úgy használ- 
ható, mint az Application.Contents: 


For Each oltem In Application.StaticObjects 
Response.Write(Application(" § oltem £ ") 5 " § 

4 Application(oltem) § "cbr2" ) 

Next 


Az egyetlen különbség az, hogy ebből a kollekcióból nem töröl- 
hetünk elemeket (azok elvesznek maguktól a webalkalmazás új- 
raindításakor) . 


A global.asa fájl 
Mint azt már a Session objektum ismertetésekor röviden leír- 
tam, a global.asa fájl egy speciális állomány, amit az ASP alkal- 
mazás gyökérkönyvtárában kell elhelyezni (de a használata 
nem kötelező). A fájl arra való, hogy ebben helyezzük el a glo- 
bális objektumokat létrehozó és eseményeket kezelő kódrészle- 
teket, úgyis mint: 

"0 az Application objektum eseményeit (létrehozását, 
megsemmisítését) kezelő rutinok (Application OnStart és 
Application OnEnd) 

0 a Session objektumok létrehozását és megsemmisítését 
kezelő eljárások (Session OnStart és Session OnEnd) 

0 globális objektumok létrehozása az OBJECT: elem 
segítségével 

"0 típuskönyvtárak (type libraries) betöltése 
A global.asa fájlban található rutinokat cSCRIPT5-/SCRIPT5 
elemek közé kell elhelyezni. A statikus objektumok létrehozá- 
sára szolgáló -OBJECT: elemet a cSCRIPT:5 blokkon kívülre kell 
elhelyezni, míg a típuskönyvtár-definíciók a blokkon kívülre és 
belülre egyaránt kerülhetnek, de érdemes azt is már a fájl ele- 
jén, a SCRIPT: blokkon kívül letudni. 

Ha a global.asa fájl tartalma megváltozik, az IIS minden 

már megkezdett kapcsolatot kiszolgál, és csak azok lezárá- 

sa után tölti be az új változatot. Ez természetesen az 
összes Session és az Application objektum lezárását és új- 
bóli megnyitását is jelenti. A global.asa betöltése és fel- 
dolgozása során az IIS nem fogad új kapcsolatokat, a fel- 
használók ezidő alatt csinos kis hibaüzenettel találkoznak 
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(a kérés nem szolgálható ki, az alkalmazás újraindul"). 


Események a global.asa-ban 

A global.asa-ban négy különféle eseményt kezelő rutint defi- 
niálhatunk, ezek az Application OnStart, Application OnEnd, 
Session OnStart, és a Session OnEnd. Lássunk egy mintát: 


LxSCRIPT LANGUAGE- VBScript" RUNAT-" Server"5 


Sub Application OnStart 
Application("appstarttime") - Now 
End Sub 


Sub Application OnEnd 
End Sub 


Sub Session OnStart 
Session("starttime") s Now 
Set Session("oFS") 5 
W — Server.CreateObject("Scripting. 
GW  Filesystemobject") 
End Sub 


Sub Session OnEnd 
Set Session("oFS") - Nothing 
End Sub 


£/SCRIPT2 


"2 Application OnStart: a webalkalmazás indulásakor, egysze- 
ri alkalommal fut le. 

2 Application OnEnd: az alkalmazás leállításakor fut le, az 
alkalmazás életében ugyancsak egyszer 

"0 Session OnStart: Session objektum létrehozásakor, gyakor- 
latilag minden új felhasználó belépésekor hajtódik végre 

"2 Session OnEnd: ez pedig a Session lezárásakor lép műkö- 
désbe. (például ha időtúllépés vagy Session.Abandon() 
hívása miatt az IIS megszünteti a session-t) 

Nézzünk rá egy pillanat erejéig az Application OnStart rutinra: 

írunk az Application objektumba, és mégsem zároljuk előtte? 

Nem lesz ebből baj? Nem, ugyanis ez az esemény egyszer és 

csakis egyszer következik be, mégpedig az alkalmazás élettar- 

tama legelején, amikor másnak még esélye sincs az Applicati- 

on objektumhoz hozzáférni. Ez az egyetlen hely, ahol nem kö- 

telező használni a Lock/Unlock metódust. 


Objektumok és típuskönyvtárak 
Az objektumok létrehozásának módját a Session leírásánál már 
megismertük: 


LOBJECT RUNAT-Server SCOPE-Application ID-"oGFSO" 
$  PROGID-"Scripting.FileSystemoObject"5 


A különbség csak annyi, hogy a scope (futási, létrehozási kör- 
nyezet) most nem Session, hanem Application lesz. Ezután 
az OGFSO objektumot a webalkalmazás minden scriptjé- 
ben közvetlen hivatkozással elérhetjük, és az megjelenik az 
Application.StaticObjects kollekcióban is. Ismét elmondom, 
hogy nagyon kell ügyelni arra, hogy az Application objektum- 
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ban csak Both, free threaded objektumokat tároljunk (ha c0B- 
JECT: segítségével szeretnénk rossz objektumot létrehozni, az IIS 
hibát jelez, a dinamikus létrehozásnál viszont nem, ott csak ké- 
sőbb, a fura működés során derülhet fény a problémára). 

A COM objektumok általában típuskönyvtárakat is tartalmaz- 
nak. Ezekből a típuskönyvtárakból lehet kiolvasni az objek- 
tum metódusainak, jellemzőinek a listáját, de sokszor min- 
denféle konstansokat is. 

Ha például egy fájlt meg szeretnénk nyitni olvasásra a 
FilegystemObject segítségével, a következőt kell írnunk: 


Set oFSO - Server.CreateObject( 
b "Scripting.FileSystemoObject") 
Set oFile - oFSO.OpenTextFile(,file.txt", 1) 


Ehhez tudnunk kell, hogy az OpenTextFile metódus második 
paraméterének 1 értéke az olvasást jelenti (ForReading). Ha 
azonban a global.asa tetején megadjuk a következő definíciót: 


€1--METADATA TYPE-"TypeLib" FILE-"scrrun.dll"--5 


(az scrrun.dil tartalmazza többek között a FileSystemObject ob- 
jektumot), akkor így is írhatjuk:: 


Set oFSO - Server.CreateObject( 

S.  "Secripting.Filegystemobject") 

Set oFile - oFSO.OpenTextFile("file.txt", 
G — ForReading) 


A számérték helyett tehát használhatók a típuskönyvtárban 
definiált konstansok, amelyek sokszor (nagyon sokszor) 
megkönnyítik az ember munkáját. 


A Server objektum 

A Server objektum is egy és oszthatatlan, és főleg kényelmi 
szolgáltatásai miatt hasznos. Gondoltunk-e már például arra, 
hogy ezt írjuk ki a felhasználó böngészőjébe: , Vízszintes vo- 
nal: cHR:". Ha ezt elküldjük a böngészőbe, megjelenik a feli- 
rat, majd maga a vízszintes vonal, hiszen a böngésző értel- 
mezi a kódban található HTML tagot. Ha a HTML elemet ma- 
gát szeretnénk megjeleníteni, a c jelet 8.lt; a 2-t pedig 8gt; 
entity-vel kell helyettesítenünk, tehát valahogy így: ,Víz- 
szintes vonal: 8lt;HRg.gt;". Ezen kívül még sok más elemet is 
kódolni kell, nem beszélve a speciális karakterekről. Szeren- 
csére itt van a Server.HTMLEncode() metódus, ami elvégzi 
ezt a kódolást (htmlenc.asp): 


Response.Write( Server.HTMLEncode("Nesze CHR2") ) 


Házi feladat: Miért kellett a htmlenc.asp kódjában a Ser- 
ver.HTMLEncode() metódust duplán használni? 


A HTMLEncode() azért is nagyon fontos, mert okos használa- 
tával elkerülhetjük az úgynevezett Cross Site Scripting [3] hi- 
bát. Ezt a fontos biztonsági hibát az okozza, hogy egyes web- 
oldalak (akár hibaüzenet formájában is) válogatás nélkül, és 
kódolatlanul visszaküldenek bizonyos, részükre előzőleg áta- 
dott szövegrészeket. A crosssite.asp például bekéri a felhasz- 
náló nevét, majd kiírja a vonal alá. Írjuk be névnek az, hogy: 
cscript: alert((Most formázom a winchesteredet!); c/scriptz 
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Mi történik? A buta kód simán visszaküldi, amit kapott, be- 
le a HTML kódba. A baj azért nagy, mert a gyanútlan felhasz- 
nálót bárki egy megfelelően előkészített URL segítségével 
egy ugyancsak gyanútlan webkiszolgálóra irányíthatja, és 
már fut is a nem várt script. 

A másik hasznos kódoló metódus a Server. URLEncode(). Mint 
azt talán mindenki tudja, az URL-ekben nem szerepelhet akár- 
milyen karakter. Ami nem megszokott, azt kódolni kell, álta- 
lában 9oxx formában, ahol xx a karakter hexadecimális kódja. 
(Még a szóközt is helyettesítik, -4- jellel) . Ha URL-eket , építünk" 
fel az ASP oldalainkban, mindig használjuk ezt a metódust is. 
Az urlenc.asp oldalon kipróbálható a kódolási művelet. 

A Server.MapPath() nagyon gyakran használt metódus. Arra 
való, hogy a virtuális könyvtár- és fájlneveket (pl. 
http://localhost/asp4/default.asp) valós fájlnevekké alakítsa 
(pl. C:Vinetpub Iwwwrootlasp4 Idefault.asp). A mappath.asp 
segítségével ezt is ki lehet próbálni. Ha a MapPath()-nek áta- 
dott virtuális név ,/" vagy ,V karakterrel kezdődik, akkor a 
virtuális gyökérkönyvtártól, ellenkező esetben pedig a hívás 
helyétől relatív fájlnevekkel dolgozik (nem lesz ugyanaz az 
eredménye tehát a ,,default.asp" és a , /default.asp" kódolásá- 
nak - kivéve ha éppen a gyökérkönyvtárban ,,állunk"). Termé- 
szetesen használhatók a ,,." és ,,.." karakterek, azaz mozogha- 
tunk a virtuális könyvtárak által alkotott térben (a ,,." az ak- 
tuális, a ,,.." pedig a virtuális szülőkönyvtárra mutat). A Ser- 
ver.MapPath() metódust nem használhatjuk a global.asa App- 
lication OnEnd eseményének kezelése közben, egyébként pe- 
dig legyünk óvatosak, mert a global.asa-ban meghívott Map- 
Path() nem a global.asa, hanem a felhasználó által megnyit- 
ni kívánt fájl alapján dolgozik. 

A Server.ScriptTimeOut beállításával a scriptek időtúllépé- 
sének határát növelhetjük meg (ez az érték nem lehet ala- 
csonyabb, mint a tulajdonságlapokon beállított alapértelme- 
Zés), illetve kérdezhetjük le. 

A Server.Transfer() és a Server.Execute() két, az IIS5-ben 
új szolgáltatás. A Server.Transfer() metódus egyszerűen átad- 
ja a vezérlést az alkalmazásban található másik .asp kód- 
nak. Minden átvett adat megmarad, többek között a Reguest 
objektum teljes tartalma is. A Server.Transfer() kiválthatja a 
Response Redirect() használatát, mert ehhez nincs szükség a 
böngésző közreműködésére (és így felesleges hálózati forga- 
lomra). Természetesen ez a megoldás csak akkor működik, ha 
webkiszolgálón belül szeretnénk átirányítani a felhasználót. 
A Server. Execute() szubrutinszerűen végrehajtja az adott ol- 
dalt, majd a végrehajtás befejezésre után visszatér az erede- 
tihez (mintha csak beszúrtuk volna a kódot). Ennek előnye az 
c1-- include --s kitétellel szemben az, hogy itt akár dinami- 
kusan is generálhatjuk a futtatandó oldal nevét. 

A Server.GetLastError() visszaadja az utolsó ASP hibának ada- 
tait tartalmazó ASPError objektumot. Erről, és az ASP oldalak 
hibakezeléséről a következő számunkban lesz szó. 

Végül, de egyáltalán nem utolsósorban: a Server.CreateObject( 
metódus létrehoz egy adott objektumot. Ezt már nagyon 
sokat használtuk, anélkül, hogy tudtuk volna, pontosan mit 
jelent. Ha a létrehozott objektum tartalmaz OnStartPage 
metódust, azt is meghívja. 
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A Server.CreateObject() mellett objektumok létrehozásá- 
ra használhatnánk egyszerűen a CreateObject() hívást is. 
Ez utóbbi nem az IIS, hanem a scriptmotor szolgáltatá- 
sa, ezért használata az ASP oldalakban — néhány kivétel- 
től eltekintve — nem ajánlott. 


Az objektum addig marad életben, amíg azt nem töröljük, il- 
letve az ASP oldal végrehajtása véget nem ér. Ha az objek- 
tumot a Session vagy Application objektumba töltöttük, ak- 
kor az objektum élete csak az adott Session vagy Applicati- 
on objektum megszűnésekor ér véget. 

Egy létrehozott objektumot úgy törölhetünk, ha a változónak 
más értéket adunk (akár szöveget is, de elterjedt és szép 
megoldás a Nothing): 


! Létrehozzuk: 

Set oFSO - Server.CreateObject( 
4  "Scripting.FileSystemoObject") 
" Megszüntetjük: 

Set oFSO - Nothing 


Naplózás az eseménynaplóba 
Néhány résszel ezelőtt bemutattuk a Response.AppendToLog() 
metódust, amelynek segítségével írni lehet az IIS szöveges 
naplójába. Az ilyen bejegyzések feldolgozása viszonylag ne- 
hézkes, ráadásul - ha még emlékszünk - vannak olyan nap- 
lóformátumok is, amikor ez a módszer nem vezet eredmény- 
re. Szerencsére a Windows Scripting Host-nak köszönhetően 
a feladatot sokkal elegánsabban is megoldhatjuk. A Windows 
Scripting Host (és vele együtt természetesen a teljes WSH ob- 
jektummodell) már az Option Pack 4-gyel bekerül(hetet)t a 
Windows NT 4.0-ba, és azóta természetesen a Windows 2000 
scriptprogramozásának lelkét képezi. A WSH objektummo- 
delljét szerencsére ASP oldalakból is elérhetjük (egy későbbi 
alkalommal majd összefoglaljuk a lehetőségek teljes palettá- 
ját, aki addig is kíváncsi lenne, a WSH objektummodell leírá- 
sát itt találja: [4]). 
Visszatérve a témához, a WScript.Shell objektum LogEvent() 
metódusa lehetővé teszi, hogy belekontárkodjunk a Windows 
NT/2000 eseménynaplójába. (Windows 9x esetén a bejegyzé- 
sek a Windows könyvtárban, a wsh.log fájlban jönnek létre). 
A LogEvent() metódus három paramétert vár, amiből az első 
kettőt kötelező megadni, a harmadiknak pedig csak Windows 
NT/2000-n van értelme: 
"0 A bejegyzés típusa (0: Success, 1: Error, 2: Warning, 4: 
Information, 8: Audit Success, 16: Audit Error) 
"0 A bejegyzés szövege 
"0 Opcionálisan a Windows NT/2000 számítógép neve, ahol 
a bejegyzést létre kell hozni (természetesen csak a meg- 
felelő jogosultságok megléte esetén) 


cz 

Set oShell - Server.CreateObject("WScript.Shell") 
oShell.LogEvent 0, "Hello from ASP!" 
oShell.LogEvent 1, "ERROR from ASP!" 
oShell.LogEvent 2, "Warning from ASP!" 
oShell.LogEvent 4, "Info from ASP!" 
oShell.LogEvent 8, "Audit Success from ASP!" 


oShell.LogEvent 16, "Audit Error from ASP!" 
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DEVELOPER ASP SuLti (IV. RÉSZ) 


Set oShell - Nothing 
sz 


A fenti példában (logevent.asp) a Server.CreateObject() me- 
tódus segítségével létrehoztunk egy Shell objektumot, elké- 
szítettünk néhány bejegyzést, majd jó kiscserkész módjára 
kitakarítottunk magunk után (az objektumváltozó értékét 
Nothing-ra állítva felszabadítjuk az objektum által lefoglalt 
erőforrásokat) . Az eredmény az ábrán látható: 
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[Application Log 6 event(5) 




















































Event ] 


Date: 2001. 03. 18. Source: WSH 


Time: 20-49 Category: None 
Type: None EventID: 0 
User NZA 


Computer: TWILIGHT 


Description: 


5 A WScript.Shell objektum segítségével készített bejegy- 
zések az Application Log naplóban láthatók 


A generált naplóbejegyzések (az audit log is) az esemény- 
napló Application Log-jába kerülnek, a Source mezőben a 
"WSHK" felirat szerepel. Ha a bejegyzést megnyitjuk, a leírás 
mezőben láthatjuk az általunk megadott szöveget. 


Fülöp Miklós 
mick Onetacademia.net 


felet 


Hello from ASPI 


Time [Source [ category TEvent T user  T computer 
3 Ő Failure Audit 2001. 03. 18. 20:49:46 WSH — None 22 NJA TWILIGHT 
[seem Gf success Audit 2001,03. 18. 20:49:46 WSH  None 8 NIA  TWILIGHT 
1] System Log Dinformation — 2001.03. 18. 20:49:46 WSH  None 4 NA TWILIGHT 
[ÓN warning 2001. 03. 18. WSH. None 2 NIA  TWILIGHT 
ÉdEror ————— 2001.03.18. WSH None 1 NA TWILIGHT 

Glnformation 2001. 03. 18. 146. WSH None o NA TWILIGHT 
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A cikkben található URL-ek: 


[1] http://technet.netacademia.net/feladatok/asp/4 


[2] http://msdn.microsoft.com/library/psdk/iisref/crtc796b.htm 
[3] http://www.microsoft.com/technet/security/crssite.asp 


[4] http://msdn.microsoft.com/scripting/windowshost/doc/wshtoc.htm 


kod dda esta ges e B 


http://msdn.microsoft.com/library/psdk/iisref/vbob7ábw.htm 
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K: Megpróbáltam a kiszolgálón átállítani a fájltípus-összeren- 
deléseket, illetve megpróbáltam volna, ha nem lenne szürke a 
menüpont. (Explorerben Tools-2Folder options-eFile types). 
Úgy érzem, nem követtem el semmi olyasmit, amivel ezt a 
büntetést kiérdemeltem. Miért szürke? 

V: Van egy-két ilyen eltünedező szolgáltatás, egy korábbi 
kérdésben például arra panaszkodott valaki, hogy az Offline 
Files tűnt el szőröstül-bőröstül. Mindkét korlátozás a Termi- 
nal Services telepítése miatt következett be. A Terminal Ser- 
ver futtatása összeegyeztethetetlen bizonyos más funkciók 
használatával. Sajnos nem tudjuk megmagyarázni, hogy a 
fájlkiterjesztés megváltoztatása, és az Offline Files mit árthat 
a Terminal Servernek - ezt Redmondban biztosan meg tud- 
nák indokolni - mindenesetre ez van, tehát ezt kell szeretni. 
Forrás: NetAcademia Windows 2000 lista 


K: Van-e DOS-os kliens Windows 2000-hez? 

V: Van-de-nincs. Ez azt jelenti, hogy a régi DOS-os kliensek 
természetesen tökéletesen működnek a Windows 2000-rel, 
de eltűnt az operációs rendszerből az NT4-ből megismert flo- 
pigenerátor. Azaz, ha nincsen készen ilyen DOS-os kliens, ak- 
kor egy jó öreg NT4 segítségével generálhatjuk le a hálózati 
kapcsolatra alkalmas flopilemezt. A Windows 2000-ben talál- 
ható Remoteboot Floppy Generator (RBFG.EXE) nem erre va- 
ló, az ugyanis a Remote Installation Serviceshez (RIS) gyárt 
indítólemezt - de az nem dosos, hanem PXE (Preboot Execu- 
tion Environment) ,operációs rendszerű", és semmi másra 
nem alkalmas, mint Windows 2000 Professional telepítésére. 
Forrás: NetAcademia Windows 2000 lista 


K: A Group Policy működésével kapcsolatban merült fel az az 
igény, hogy ne kelljen kivárni a munkaállomásokon a 90 per- 
ces késleltetést a kiértékelés automatikus beindulásáig, de ne 
kelljen ki-be jelentkezni, pláne újraindítani a gépet. Nem le- 
hetne valahogy , megsürgetni" a GPO-t? 

V: A Group Policy kiértékelése szándékosan késleltetett, hisz 
ezzel jelentős sávszélesség takarítható meg. Ha mégis szük- 
ség van a változtatások gyors, menet közbeni kiértékelésé- 
re, használjuk a SECEDIT.EXE-t parancssorból. Mivel a GPO 
számítógépekre és felhasználókra is hathat, kétféle parancs 
van ezek külön-külön frissítésére. Ha gépszintű beállítást 
szeretnénk hirtelen frissíteni, (például a Log On Locally jog 
megváltozását szeretnénk életbe léptetni) használjuk a 


SECEDIT /REFRESHPOLICY MACHINE POLICY 


parancsot, míg ha felhasználói beállításról (tűnjön el a RUN 
menüpont!) van szó, a parancs így néz ki: 


SECEDIT /REFRESHPOLICY USER POLICY 


Forrás: NetAcademia Windows 2000 lista 
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K: A DNS Server tulajdonságlapján két helyen is van ,,recur- 
sion" pipa. Feltételezve, hogy tudom mi a DNS rekurzió, mi a 
különbség a két pipa között? 

V: A különbség óriási. A Forwarders fülön lévő pipa hatására 
a DNS Serverünk a helyben megválaszolhatatlan kéréseket 
csak és kizárólag a beállított forvarderek-nek küldi tovább, s 
ha azok nem válaszolnak, hibaüzenetet küld a kérdezőnek. 
Azaz ez a pipa , csak" annyiban érinti a munkaállomásokat, 
hogy ha a forwarder DNS kiszolgáló lehal, akkor ,vége a 
külföldnek", egyéb változás nincs. Ezzel szemben az Advan- 
ced fülön lévő beállítás súlyosan visszahat az ügyfélgépekre, 
mert azt mondja ki, hogy a DNS Server ne járjon el (rekurzi- 
ve) a neten a kliensek nevében, hanem ha egy kérdést nem 
sikerül helyben feloldania, akkor a továbblépés útjára muta- 
tó úgynevezett Referral rekordot küldjön a kliensnek - oldja 
meg a problémát maga! No ez utóbbi tipikusan nem fog men- 
ni a munkaállomás belső IP címéről. Ezt a pipát NE bántsuk! 





ÍparaN properties ssazátllliki ET) 
Logging 1 Monitoring 1 Secuy 
interföces Forwatders — ] Advanced] Root Hints 
1 
Forwarders help resolve any D EESZNIZETTI E 213 
Logging 1 Monitoring 1 Securty ji 
Fe Age zeetta Intertáces —]/ Forwarders Advanced] RootHirte] 
To add a forwarder, type ít 
Pp e. Server version number: 
ps Egesz mezon 
Server options 






ÍZIBIND secondanes 
[OFad onload t bad z0ne data 
fiZEnable round rob 

iZEnable netmask ordeing 
ÖSecuwe cache against poluton 


Mulibte (UTFB) zi 


Forward time-out (seconds ame checking 





TT Bopotuzzreamgod Load zone döla on statu [iomAcive Directowy and regity 7 
IT Enable automatic scavenging of stale records . 
[ Scavenging period o days 7 
"Reset to Default 





5 A két Recursion pipa 
Forrás: NetAcademia Windows 2000 lista 


K: Van két Exchange 5.5 telephelyünk, melyek közül eddig 
csak az egyikben volt SMTP konnektor. Most a másik telephely 
is kapott bérelt vonalat, és ugyanazt az SMTP email címet sze- 
retnék használni. Be is állítottam mindkét telephelyen a Site 
Addressingben a (2vallalat.hu címet, - erre a két telephely le- 
szakadt egymásról, megszűnt a belső levelezésünk! 

V: A probléma oka természetesen az azonos SMTP cím, mert 
így a szomszéd telephelyre menő leveleket az Exchange nem 
küldi át, hisz a helybéli telephely ,közelebb van". Magyarul 
belezavarodik. 
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Evallalat.hu 





9 A levél útja két azonos nevű SMTP tartomány között :) 


Ám itt meg - értelemszerűen -— nincs olyan nevű mailbox, 
mint ahova a levél menne. Így a levelezésnek valóban 
annyi. Megoldási lehetőségek: 

1) Ne legyen azonos a két telephely SMTP címe. Ez 
hosszas folyamat, DNS regisztráció, MX rekord, név- 
jegykártyacsere az összes dolgozónál stb. 

2) Ha a cím marad, akkor pedig NE legyen két SMTP kon- 
nektorunk. A másik telephelyen le kell szedni! S hogy 
akkor a telephelyek hogyan levelezzenek egymással az 
Interneten? X.400-zal! 

3) Térjünk át Exchange 2000-re. Ott ezt a problémát leke- 
zeli a sokkal intelligensebb routing algoritmus. 

Forrás: NetAcademia Exchange 2000 lista 


K: Adott egy házirend ami egy szervezeti egységhez tartozik. 
Ezt a házirendet szeretném alkalmazni kisebb módosítások- 
kal egy másik szervezeti egységnél is. Hogyan lehet megolda- 
ni azt, hogy ne kelljen újra beállítani minden egyes szerve- 
zeti egységnél ugyanazt, hanem újra fel lehessen használni 
az egyszer már megírt házirendet? 

V: Úgy, hogy a következő felhasználási helyen (0U-n) nem 
New.. hanem Add.. gombot nyomsz, és ezzel egyszerűen 
belinkeled a már meglévő policy-t. Ám ekkor egyetlenegy 
példányod lesz, tehát ha az egyik helyen módosítod, a má- 
sikon is módosul. Ha valóban másik, ám ugyanolyan poli- 
cy-t kellene létrehozni, akkor a következő módszer segít: 
1) Áss le a policy-fájlokhoz a 
winnttsysvoltsysvolidomained policies könyvtárba. 
Itt ronda, GUID nevű alkönyvtárakat látsz. 

Be zlOl2] 





ETUTTNSEZTEZÜNÉES TETT: 
] Ele Edt Wew  Favorites Iools Help 

] Back " 2 - EJ] Asearh GyFolders EgHstory [íg OZ X 7] EH- 
[Address [DJ EXWINNTISYSVOLtsysvolnetacademia.fmipolces 2] ése 
SE -4 — 


Elv A] 143182F340-O160-1102-945F-O0CO4FBIS4F9) 
MH Li [DJ 46AC1786C-O16F-1102-945F-OOCO4ÍBOB4F9) 


Policies 























al 
[2 object(9) bytes 





KH My computer 4 





0 GUID nevű könyvtárak 


Ebben ülnek a policy-fájlok. Most már csak meg kellene ha- 

tározni, hogy melyik melyik. 

2) Nyisd meg az 0U-t az Active Directoryban, állj rá a 
policyra, és nyomj , Properties"-t. Itt nézd meg a poli- 
cy GUID-jét: az egyik könyvtárnévvel egyeznie kell. 
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Default Domain Controllers Policy Properties; 


2131 
General [ Links ] Secuny] 


Es Default Domain Controllers Policy (hofeherke.netacademia.ím) 


TF Summary 
Createdt 4/7/2000 10:16:09 AM 
Modífied: 3/5/2001 12:45:28 PM 
Revisions: 90 (Computer), 0 (Use) 


Domain: netacademia. Ím 
Unigue name: (SGAC1786C-OTGF-11D2-945F-00CO4(B984F39) 


r Disable: 


To improve performance, use these options to disable unused 
Parts of this Group Policy Object. 


IT Dizabie Computer Configutalion selinad 
IT Disable User Configuration settings 











o A policy GUID-je 


Innentől már csak kipi-kopi kérdése az egész! 
Forrás: NetAcademia Windows 2000 lista 


K: Hogyan lehetne megszabadulni az Accessoires, Games, Ac- 

cessibility és egyéb haszontalanságoktól Windows 2000 ese- 

tén? Sajnos az Add/Remove Windows Components nem teszi 

lehetővé az eltávolításukat. 

V: A Windows 2000 Professional telepítésekor a Games, Ac- 

cessories, Multimedia, Accessibility options valóban auto- 

matikusan települ, és ezután már a Control Panel Add/Remo- 

ve Programs menüjében sem jelenik meg. De van megoldás: 

1) Keressük meg, és nyissuk meg Notepad-ben a 
9osystemroot9oinfisysoc.inf fájlt 

2) Keressük meg az "old base components" sort 

3) Minden megjeleníteni kívánt komponensnél töröljük a 
HIDE feliratot (hogy a vesszőt is kell-e, az nem egyér- 
telmű), pl.: 
Games-ocgen.dll, OcEntry, games.inf, HIDE,7 helyett 
Gameszocgen.dil,OcEntry, games.inf, , 7 

4) Töröljük a HIDE opciót az AccessUtil- sorból 

5) Save and Enjoy 

Forrás: NetAcademia Windows 2000 lista 
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BILL GATES MONDJA 





A következő technológiai lépés a mindenre használható 
hozzáférés lesz. 

Meglepő, de a ,konvergencia" fogalma már több mint húsz 
éve bekerült a csúcstechnika lexikonjába. 

Az elmúlt évek nagyobb részében a konvergencia két dolgot 
jelentett: a számítástechnikai, a szórakoztató elektronikai 
és a telekommunikációs iparágak közeledését, és az eszkö- 
zök, például a PC, a TV és a telefon összevonását. 

De a 21. század közeledtével a kifinomult digitális techno- 
lógiák és a sávszélesség robbanásszerű növekedésének ígé- 
rete egy harmadik féle konvergenciát hoz létre, mely alap- 
vetően megváltoztatja az életünket, jobban, mint ahogy 
azt eddig gondoltuk volna. Ez fogja biztosítani az informá- 
ció korának előnyeit bárkinek, bármikor, bárhol. 

Olyan korban élünk, melyben a hang, az adatok és a moz- 
góképek bitekből állnak. Egyesekből és nullákból, melyeket 
a lehető legnagyobb sávszélességű, vagy az adott szolgál- 
tatáshoz legalkalmasabb adatátviteli csatornán juttatnak el 
hozzánk. A biteknél nem számít, hogyan jutnak el rendel- 
tetési helyükre, csak az, hogy a megfelelő sorrendben és 
időben érjenek oda. Az, hogy a bitek mindenütt jelen van- 
nak, máris lehetőséget biztosít olyan hibrid készülékek 
(például a modern PC-k, WebTV-k, kábelmodemek, intelligens 
telefonok) létrehozására, melyeket az utóbbi két évtizedben 
elektronikai termékként megálmodtak. 

De ez még csak a kezdet. Ötvözzük a digitális technológiát 
és a fejlett szoftvereket, a kisebb és erősebb mikropro- 
cesszorokat, az üvegszálas és vezeték nélküli hálózatok sáv- 
szélességének exponenciális növekedését, és sokkal jobban 
felhasználható, észrevétlen, mindenre alkalmas kapcsolato- 
kat kapunk. Ez megváltoztatja a konvergenciát, azaz, bár a 
számítógépek, a telekommunikáció és a szórakoztató elekt- 
ronikai termékek összevonódnak, az intelligens eszközök 
következő generációja általában nem. 

Ezek a mindenre használható kapcsolatok összegyűjtik a 
számunkra szükséges információkat és szolgáltatásokat, és 
elérhetővé teszik azokat, függetlenül attól, hogy hol va- 
gyunk, mit csinálunk, és milyen eszközt használunk. Nevez- 
zük ezt virtuális konvergenciának, hiszen minden, amit 
akarunk egy helyen van, de ez a hely mindig ott van, ahol 
akarjuk, nem csak otthon, vagy az irodában. 

Ennek eredménye olyan intelligens eszközök halmaza lesz, 
(például a zseb PC-k, a , tábla PC-k", a webes képességekkel ren- 
delkező telefonok és autóba szerelt PC-k), melyek kihasználják 
ezeket a lehetőségeket. A fájljaink, az időbeosztásunk, a cím- 
jegyzékünk és bármi más amire szükségünk lehet, automatiku- 
san replikálódni fog ezekre az eszközökre, mert mindegyik 
össze tud majd kapcsolódni egymással. 

A virtuális konvergencia átveszi az asztali gépeink szerepét, és 
mindenhol elérhetővé teszi az információkat, ahol csak szük- 
ségünk van azokra. De hogy segítsen elkerülni azt, hogy túl 
sok információhoz jussunk, intelligensen fogja ezt végrehajta- 
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Bárki 
Bármikor 
Bárhol 


ni. Ha például szombat délután meccset nézünk a stadionban, 
a hálózat tudni fogja, hogy a játékosokról szóló információk, 
vagy például egy online hotdog-rendelési űrlap zseb PC-nken 
való megjelenítése szükséges, és nem az adóbevallásunk, vagy 
a másnapi utazásunk útitervére vagyunk kíváncsiak. 

Még sok mindent kell tenni, hogy ez valóra válhasson. El- 
sősorban nagyjából ugyanazt, mint amikor az emberek azo- 
nos nyelven beszélnek. Ahhoz, hogy megértsék egymást, 
hatékonyan együttműködjenek és kommunikáljanak egy- 
mással, az intelligens eszközöknek is közös nyelvet kell 
sbeszélniük". Ennek legegyszerűbb és legcélszerűbb módja 
a létező Internetes szabványok alkalmazása. Az iparág erre- 
felé mozdul, de még mindig igen sok a tennivaló. Ez azon- 
ban még nem elég, jelentős tőkebefektetésre is szükség 
van, ha azt akarjuk, hogy a nagysebességű, szélessávú kom- 
munikáció széles körben elérhető legyen az Egyesült Álla- 
mokban (Hát még Magyarországon... :( - A ford.) . 

Hogy ez megvalósulhasson, egyre több megállapodás, szövet- 
ség és konzorcium jön létre, melyekben számítástechnikai, 
szórakoztató elektronikával foglalkozó, telekommunikációs, 
Internetes és kábelhálózatokat üzemeltető cégeknek van ér- 
dekeltségük. Mivel mindenkinek szembe kell nézni az életké- 
pes üzleti modell kialakításának kihívásaival, e cégek néme- 
lyike tönkre fog menni. Két dolog azonban biztos: a minden- 
hol elérhető vezeték nélküli, és a nagy sávszélességű adathá- 
lózatok kezdenek kiépülni, és a különféle intelligens eszkö- 
zök, melyekre ezeknek a hálózatoknak az eléréséhez szükség 
lesz, hamarosan megjelennek a piacon. Ezek együttese valóra 
válthatja a virtuális konvergenciában rejlő lehetőségeket. 


Bill Gates 
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Időpont: 2001. 04. 25. 
A konferencia elsősorban üzemeltetési vezetőknek és rendszer üzemeltetőknek szól. Segítséget nyújt a nagy- és kö- 
zépvállalatok informatikusainak és rendszergazdáinak, hogy a már meglévő Microsoft technológiákra épülő rend- 
szereiket még megbízhatóbban és egyszerűbben üzemeltethessék. Szeretnénk bemutatni és átadni mindazt a tu- 


dást, ami a Microsoftnál és partnereinél az üzemeltetési és terméktámogatási gyakorlat során felhalmozódott. 


Rendszerfelügyelet Windows 2000 környezetben 

Időpont: 2001. 05. 02. i I 

Az előadás a Windows 2000 alapú vállalati környezetek rendszerfelügyeleti és üzemeltetési kérdéseit tárgyal- 
ja. A gyakorlatias megközelítésű előadáson egy kiépített Windows 2000 Active Directory, Systems Manage- 
ment Server (SMS) 2.0 és Microsoft Operations Manager környezetben mutatjuk be az asztali gépek és alkal- 


mazások, illetve a kiszolgálók felügyeletét és a napi üzemeltetési teendőket. 


Üzleti Intelligencia: adatraktárak létrehozása és az adatok elemzése 

Időpont: 2001. 05. 16. 

Minden vállalat használ adatbáziskezelőt, de vajon kihasználja-e a felhalmozott üzleti célú adatokban rejlő 
információkat? Az előadások az adattárház kezelés folyamatának legfontosabb lépéseit tekintik át. Ismerte- 


tett technológiák: Data Transformation Services, OLAP kiszolgáló (Analysis Services), MDX, ADO DM. 


Sokan megtudják mondani, hogy HOGYA 


"De 


TELET ZBTAT Le [ÁGA 
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1. Biztonsági technológiák 
rendszergazdáknak, 3 nap 


Titkosítási algoritmusok (DES, RSA, MD5 stb.) elmélete és gyakorlata 

Az autentikáció biztonsága (Kerberos, NTLM, NTLMv2) 

A nyílt kulcsú titkosítási technológia nagyvállalati, gyakorlati alkalmazása 
(Certificate Server, SmartCard, biometrikus azonosítás) 

Biztonságot növelő technológiák bevezetése (IPSec, VPN, LZTP, Encrypting 
File System stb.) 


2. Biztonságos levelezőrendszer kialakítása MS Exchange alapokon 
gyakorlott Exchange rendszergazdák számára, 3 nap 


Titkosítás és digitális aláírás az elektronikus levelezésben (S/MIME) 

Az Exchange Server védelme, adminisztratív szerepek, jogosultságok, 
mentés, visszaállítás, journaling 

Tűzfal vs. Exchange Server, SMTP relay beállítások, spam védelem, SSL, 
TSL, nyílt kulcsú titkosítás felhasználása, MAPI, POP3, IMAP, OWA, LDAP 
protokollok veszélyei. 


A legjobbakat tanítjuk! 


1105 Budapest, Ihász utca 13. "e Tel.:263-2732 


3. 


4. 


Bendszer- 
felügyeletmentes 
hálózatról (ZAK, 
ZAVV]? 
Feltörhetetlen 
hálózatról (C2)? 


Elérhetetlen, de megközelíthető célok. Az első kettő elérésében sajnos nem segít- 
hetünk. De a harmadik cél megközelítésében sokat tehetünk Önért. Világszínvonalú, 
egyedi Security tanfolyamainkon megtudhatja, mitől döglik a hacker! 





. Hálózatunk védelme a támadásokkal szemben 

izton: ! foglalkozó szakemberekn 
Kalóz-eszközkészlet (Denial Of Service, Buffer 
Overrun, hálózatelemzés, trójai falovak, vírusok, jelszófeltörés, hátsó ajtók) 
A Windows 2000 biztonsági elemei (fájlrendszerek, regisztrációs adat- 
bázis, hálózati adatforgalom) 
Védekezés: tűzfalak, proxyk 
Aktív védekezés: Intrusion Detection 

. Programozzunk biztonságosan! 


programozók számára, 3 nap 


Elmélet: védett mód, kernel, memóriakezelés 

Programozási gyakorlatok, rosszul és jól megírt kódok 

A Buffer Overrun hatásai user és (app es service)--kernel módban 
RFC implementation errors 

JAVA, ActriveX, homokozó, scriptek 

Worm vírusok elemzése (lloveyou) 

CryptoAPI, Smart Card API 


VÉT a adi s üV0 HŰ 
MEL FALADHMIK 
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